Skip to main content
POST
This endpoint gives Yuno visibility over the traffic you process directly with your providers, outside Yuno’s transaction path. Each accepted event is persisted as a regular Yuno payment, differentiated by the origin field:
  • origin: YUNO — payments processed by Yuno (every existing payment).
  • origin: REPORTED — payments that entered through this API.
Reported payments appear in the dashboard, in GET /v1/payments, and in analytics — filtered by origin — but Yuno never processes them: no routing, no provider calls, no retries, and no money movement. The money already moved at your provider; Yuno records the fact.
Enabled per organizationThis API requires activation for your organization. Contact your Key Account Manager (KAM) to enable it.

​
How it works

  1. You process a transaction directly with your provider (e.g. a purchase on your own Adyen account).
  2. You report it here — one event or a batch of up to 500. For latency-sensitive integrations we recommend batches of up to 100 events: the full 500-event batch is processed synchronously and can take several seconds.
  3. Each accepted event creates one payment with one transaction, with the status derived from result and the event type: a PURCHASE with result SUCCEEDED lands the payment SUCCEEDED; an AUTHORIZE with result SUCCEEDED lands PENDING with sub-status AUTHORIZED (an approved authorization is not captured money — it mirrors how Yuno-processed authorizations behave); a VERIFY with result SUCCEEDED lands SUCCEEDED with sub-status VERIFIED (the verification completed; no money moves — it mirrors how Yuno-processed verifications persist); DECLINED → DECLINED, ERROR → ERROR.
In this version the supported operations are PURCHASE (default), AUTHORIZE, and VERIFY. A VERIFY reports a card verification (zero-dollar authorization), typically reported with amount.value: 0. Lifecycle events (captures, refunds, chargebacks) are on the roadmap.

​
Retries and deduplication

There is no idempotency header on this endpoint — and none is needed. The report_id you generate per event is the deduplication key: an event whose report_id was already ingested is counted in duplicates and never ingested twice, no matter when or in which batch it arrives. Retrying a whole batch after a network failure is always safe. Because report_id alone decides, an event that reuses an already-ingested report_id with a different payload is also counted as a duplicate and silently discarded — never reuse a report_id across different transactions. The batch is processed per event: one invalid event lands in rejected[] with its reason, and the rest of the batch is unaffected.

​
The raw provider response

If you include raw_provider_response (the provider’s response payload, verbatim, up to 64 KB), Yuno stores it with defensive card-data redaction applied — primary account numbers and security codes are removed before anything is persisted. It is never returned by any API. Sending it is recommended: it lets Yuno enrich the reported payment later (network transaction references, decline reasons) without asking you for anything new.
Never send card data in the event fields. Reported events carry references and outcomes, not cardholder data. The only place a card number may transit is inside raw_provider_response, where it is redacted on ingestion.

​
Operations on reported payments

Reported payments cannot be operated through Yuno — a refund or capture request on a payment with origin: REPORTED returns 403 OPERATION_NOT_ALLOWED_FOR_REPORTED_PAYMENT. Perform the operation at your provider and report it as a new event when lifecycle events become available.

​
Errors

Errors return a code and a messages array.

​
Per-event rejections: INVALID_EVENT

INVALID_EVENT is not an HTTP error — the batch itself is accepted (202), and each invalid event is returned individually inside rejected[] with this code and its reason, while the rest of the batch is ingested normally:
Causes: invalid enum value, wrong field type, unknown field, or raw_provider_response over 64 KB.

Headers

​
PUBLIC-API-KEY
string

Your public API key.

​
PRIVATE-SECRET-KEY
string

Your private secret key. Never expose it client-side.

Body

application/json
​
account_id
string<uuid>
required

UUID of the Yuno account the reported payments belong to.

​
events
object[]
required

One event or a batch of up to 500. Events are processed per item: one invalid event never rejects the batch.

Required array length: 1 - 500 elements

Response

Batch accepted and processed per event.

​
accepted
integer

Events ingested as payments.

​
duplicates
integer

Events skipped because their report_id was already ingested.

​
rejected
object[]

Events that failed validation, each with its reason. The rest of the batch is unaffected.