Transactions

A payment is the merchant intent, a transaction is a single provider attempt. One payment can produce multiple transactions when Yuno retries or cascades.

Payments vs transactions

A payment represents the merchant’s intent to collect funds. A transaction represents a single processing attempt against a provider. One payment can have multiple transactions when Yuno retries or cascades across providers.

Why multiple transactions

Yuno creates additional transactions in these scenarios:

Scenario	Description
Provider decline	Primary provider declines, Yuno retries with a fallback provider
Provider timeout	Primary provider does not respond within the configured window
Cascading rules	Your routing configuration specifies retry behavior across providers
Capture	A separate transaction records the capture of an authorized payment
Refund	Each refund (full or partial) creates its own transaction

Transaction types

Type	Description
AUTHORIZATION	Reserves funds on the customer’s payment instrument
CAPTURE	Transfers previously authorized funds to the merchant
SALE	Combined authorization and capture in one step (auto capture)
REFUND	Returns captured funds to the customer
VOID	Releases an authorization without capturing
CANCELLATION	Cancels a pending or authorized payment
VERIFY	Zero amount card verification without charging
3DS	3D Secure authentication challenge transaction

Transaction statuses

Transaction statuses describe a single provider attempt. For the overall payment outcome (which rolls up across every transaction in a payment) see payment flow.

Status	Meaning
CREATED	Transaction initiated, not yet sent to provider
PENDING	Transaction submitted, awaiting provider response
SUCCEEDED	Provider confirmed successful processing
DECLINED	Provider or issuer declined the transaction
REJECTED	Transaction blocked by validation or fraud rules
FAILED	Processing error (network issue, provider error)
CANCELLED	Transaction cancelled before completion
EXPIRED	Transaction timed out without resolution
ERROR	Unexpected system or provider error

Transaction flows by type

Each transaction type can reach specific statuses. The table below shows every valid outcome per type.

Transaction type	Possible statuses
PURCHASE	CREATED · SUCCEEDED · PENDING · CANCELLED · EXPIRED · DECLINED · REJECTED · ERROR
AUTHORIZE	CREATED · SUCCEEDED · DECLINED · ERROR
VERIFY	CREATED · SUCCEEDED · DECLINED · ERROR
CAPTURE	PENDING · DECLINED · ERROR
CANCEL	SUCCEEDED
REFUND	CREATED · SUCCEEDED · PENDING · DECLINED · ERROR
3DS	DECLINED · ERROR
CHARGEBACK	CREATED · WON · PENDING · LOST · ERROR
FRAUD SCREENING	CREATED · SUCCEEDED · PENDING · CANCELLED · DECLINED · ERROR

How a purchase flows

The most common type. This shows every path a purchase can take.

How authorize and capture flow

Two step payment: authorize reserves funds, capture transfers them.

How chargebacks flow

View transactions

Retrieve every transaction for a payment.

curl --request GET \
  --url https://api-sandbox.y.uno/v1/payments/{payment_id}/transactions \
  --header 'public-api-key: your-public-api-key' \
  --header 'private-secret-key: your-private-secret-key' \

Each transaction includes the provider used, the provider’s raw response code, and timing. The codes below are illustrative ISO 8583 values. Actual code sets vary by provider:

{
  "transactions": [
    {
      "transaction_id": "txn_001",
      "type": "SALE",
      "status": "DECLINED",
      "provider": "provider_a",
      "provider_response_code": "51",
      "provider_response_message": "Insufficient funds",
      "created_at": "2026-02-28T10:00:00Z"
    },
    {
      "transaction_id": "txn_002",
      "type": "SALE",
      "status": "SUCCEEDED",
      "provider": "provider_b",
      "provider_response_code": "00",
      "provider_response_message": "Approved",
      "created_at": "2026-02-28T10:00:02Z"
    }
  ]
}

See the Transaction object for the full schema.

provider_response_code and provider_response_message contain the raw acquirer or issuer response. Useful for debugging declines, but they vary across providers.

Transaction vs payment status

The payment status reflects the final outcome across all transactions. If the first transaction is declined but a cascade succeeds, the payment status is SUCCEEDED even though one transaction was DECLINED.

Use payment status for business logic (order fulfillment, customer notifications). Use transaction level data only for debugging and analytics.

When to look at transaction-level data

Transaction records answer questions that payment records cannot: which provider approved the charge, which one declined and with what code, and how long each attempt took. Typical uses:

• Debugging a cascade. A payment succeeds on the second try. The transactions list shows which provider failed, the decline reason (provider_response_message), and which provider recovered the sale.
• Reconciling with a specific acquirer. Finance teams matching settlement reports to one provider filter by the provider field on transactions.
• Analyzing retry health. Approval rate per provider and average cascade depth come from aggregating transactions, not payments.

What next

Payments

Create, capture, refund, and cancel with code.

Payment flow

The conceptual lifecycle and status state machine.

Providers

How Yuno picks which provider to run each transaction against.

Transaction object

The full transaction schema in the API reference.