API Changelog

Documentation Index

Fetch the complete documentation index at: https://docs.y.uno/llms.txt

Use this file to discover all available pages before exploring further.

​

v2025-06

• Optional first and last name for customers
  The first_name and last_name fields are now optional when creating a customer via the API. If a payment provider requires them, the SDK form will prompt the user. If you are not using the Yuno SDK, ensure these fields are provided at payment creation time when required by the provider. See also: Create customer reference

• 3DS SCA exemption support
  A new optional field strong_customer_authentication_exemptions is now available under payment_method.detail.card.three_d_secure. Yuno also propagates exemption recommendations from your fraud provider through the full payment route to the 3DS gateway, and the exemption type appears in the payment response, GET API, and webhooks. See also: SCA exemptions guide

• Airline trip type field
  A new type enum field has been added inside additional_data.airline to specify the trip type: ONE_WAY, ROUNDTRIP, or MULTIPLE_DESTINATIONS. No integration changes required if you do not use airline data. See also: Create payment reference
• Airline leg ordering fields
  Two new integer fields, order and route_order, have been added inside additional_data.airline.legs to describe the order of legs within a route and across routes respectively. No integration changes required if you do not use airline leg data. See also: Create payment reference
• Transportation data struct
  A new transportations array of objects is available inside additional_data for non-airline travel bookings such as bus, train, ship, tram, and car. Each entry supports legs, passengers, and tickets sub-objects with departure/arrival details. See also: Create payment reference

​

v2025-05

• Network token enrollment for vaulted cards
  When the network tokens feature is enabled, Yuno now generates network tokens for all cards enrolled and stored in the Vault. One-time-use cards are excluded. This aligns with Visa and Mastercard network tokenization standards and improves recurring payment security and reliability. See also: Network tokens guide

• Subscription billing date control
  A new billing_date struct is available when creating a subscription, letting you define billing timing as PREPAID, POSTDATE, or a specific DAY of the month. This field is mutually exclusive with the frequency object. See also: Subscriptions guide

• Payment method expiration date field
  A new expirates_at timestamp field is now returned inside payment_method_detail.wallet for asynchronous payment methods that support it. Availability depends on provider support. See also: Create payment reference

"payment_method": {
  "type": "NU_PAY",
  "payment_method_detail": {
    "wallet": {
      "expirates_at": "2025-05-14T15:06:48.383418Z"
    }
  }
}

• Customer geolocation in payments
  A new geolocation object with latitude and longitude fields is now available inside customer_payer when creating a payment. See also: Create payment reference

"customer_payer": {
  "id": "b080db73-b12d-4710-a604-d659bce26f01",
  "geolocation": {
    "latitude": "-34.4720",
    "longitude": "-58.5300"
  }
}

• Cancel PENDING APM payments
  You can now cancel a PENDING payment created with an alternative payment method (APM) via the cancel endpoint. Previously this was restricted to card transactions only. Feature availability depends on provider support. See also: Cancel payment reference

• Subscription webhook URL support
  You can now define a webhook_url in the Developers section of the dashboard to receive subscription lifecycle events. Different event types produce distinct webhook payloads. See also: Webhooks documentation

​

v2025-04

• 3DS setup service removed
  The separate setup service call for the 3DS direct implementation is no longer required. Data collection and setup are now handled automatically inside payment creation, simplifying the integration flow. See also: 3D Secure guide

• Extended airline leg fields
  New fields have been added inside additional_data.airline.legs: arrival_airport_country, arrival_airport_city, departure_airport_country, and departure_airport_city. Also, a booking_system_code and booking_system_name are now available inside airline.tickets[].issue. No integration changes required if you do not use airline data. See also: Create payment reference

"additional_data": {
  "airline": {
    "legs": [
      {
        "arrival_airport": "AMS",
        "arrival_airport_country": "AR",
        "arrival_airport_city": "BUE",
        "departure_airport": "EZE",
        "departure_airport_country": "AR",
        "departure_airport_city": "BUE"
      }
    ],
    "tickets": [
      {
        "issue": {
          "booking_system_code": "TT01",
          "booking_system_name": "booking system"
        }
      }
    ]
  }
}

​

v2025-03

• Discounts array in order data
  A new discounts array of objects is available inside additional_data.order. Each discount entry supports id, name, and unit_amount fields. See also: Payment amount details guide

"additional_data": {
  "order": {
    "discounts": [
      {
        "id": "XYZ",
        "name": "Offer",
        "unit_amount": "100"
      }
    ]
  }
}

• Monitors flag in routing rules
  A new boolean field monitors has been added inside the routing_rules object in the payment response, indicating whether a transaction was processed through the Monitors feature. No integration changes required. See also: Payment object reference

"routing_rules": {
  "smart_routing": false,
  "monitors": true,
  "condition": {
    "id": 133892,
    "name": null,
    "description": null
  }
}

• Customer info in refund requests
  A new customer_payer object is now accepted in refund requests, allowing you to pass additional customer data (e.g., document) to providers that require it. See also: Refund payment reference

{
  "description": "Duplicate",
  "reason": "REQUESTED_BY_CUSTOMER",
  "merchant_reference": "AAB01-432245",
  "customer_payer": {
    "document": {
      "document_type": "DNI",
      "document_number": "38919283"
    }
  }
}

​

v2025-02

• OAuth2 authentication for webhooks
  Webhooks now support OAuth2 authentication. Configure authentication_url, client_secret_key, client_id, and grant_type in the Developers/Webhooks dashboard section so Yuno can obtain tokens for secure webhook delivery. See also: Configure webhooks guide
• Dedicated URL for chargeback webhooks
  You can now configure a dedicated webhook URL specifically for chargeback events. Previously, chargebacks were bundled with the Purchase trigger. Update your webhook configuration in the dashboard to use the new dedicated chargeback URL. See also: Configure webhooks guide

​

v2025-01

• Ticket data in payment orders
  A new tickets array of objects is available inside additional_data.order, supporting fields like id, name, description, type, amount, and a nested event object with address details. See also: Payment API reference

"additional_data": {
  "order": {
    "tickets": [
      {
        "id": "XYZ",
        "name": "Music",
        "type": "VIRTUAL",
        "amount": {
          "currency": "COP",
          "value": 5000
        },
        "event": {
          "id": "ADMKASLMD",
          "name": "Music festival",
          "type": "FESTIVAL",
          "date": "1990-02-28"
        }
      }
    ]
  }
}

• Subscription initial payment validation
  A new boolean field initial_payment_validation is available when creating a subscription. Set to true to continue the subscription only after a successful first payment, or false to continue regardless of the first payment outcome. See also: Create subscription reference

{
  "initial_payment_validation": true
}

​

v2024-12

• Card type selection for vaulted tokens
  When using a vaulted token for payment, you can now specify card_data.type as CREDIT or DEBIT inside payment_method.detail.card. Useful for markets like Brazil where the same card can be used for both transaction types. See also: Payment API reference

"payment_method": {
  "type": "CARD",
  "vaulted_token": "e2961d37-9898-4bac-8408-cc9f02c11cc2",
  "detail": {
    "card": {
      "card_data": {
        "type": "DEBIT"
      }
    }
  }
}

• Account funding transaction details
  A new account_funding object is available inside additional_data, supporting sender and beneficiary sub-objects with name, email, and document fields required for Account Funding Transactions (AFT). See also: AFT guide

"additional_data": {
  "account_funding": {
    "sender": {
      "first_name": "John",
      "last_name": "Doe",
      "email": "john.doe@mail.com"
    },
    "beneficiary": {
      "first_name": "Chris",
      "last_name": "Martin",
      "document": {
        "document_number": "38192019",
        "document_type": "CC"
      }
    }
  }
}

• Network transaction ID for stored credentials
  A new network_transaction_id field is now available inside payment_method.detail.card.stored_credentials. Recommended for subscription payments with enrolled cards to ensure traceability across the payment lifecycle. See also: Stored credentials guide

"payment_method": {
  "type": "CARD",
  "vaulted_token": "eb8caa17-6407-457b-960e-125d8d7a90c1",
  "detail": {
    "card": {
      "stored_credentials": {
        "reason": "CARD_ON_FILE",
        "usage": "USED",
        "network_transaction_id": "583103536844189"
      }
    }
  }
}

• Smart routing flag in payment response
  A new boolean field smart_routing has been added inside the routing_rules object in the payment response, indicating whether the transaction was processed through the smart routing feature. No integration changes required. See also: Payment API reference

"routing_rules": {
  "smart_routing": false,
  "condition": {
    "id": 133892,
    "name": null,
    "description": null
  }
}

• Trial period for subscriptions
  A new trial_period object is available when creating a subscription. Define billing_cycles and a reduced amount to offer partial or full (free) trial periods before full billing begins. See also: Create subscription reference

"trial_period": {
  "billing_cycles": "1",
  "amount": {
    "currency": "COP",
    "value": 2500
  }
}

​

v2024-11

• Card expiration fields in transaction response
  Two new fields, expiration_month and expiration_year, are now returned inside transactions.card_data in the payment response. No integration changes required. See also: Payment object reference

"card_data": {
  "holder_name": "Paco",
  "iin": "48710499",
  "brand": "VISA",
  "fingerprint": "71000db4-f8e7-4ea0-a2cc-9d9ebb76a955",
  "expiration_month": 3,
  "expiration_year": 30
}

• Recipients for split marketplace payments
  A new Recipients API allows you to register recipients with multiple provider mappings before sending split payments. Use recipient_id in the split_marketplace array instead of provider-specific IDs when multiple providers are involved. See also: Split payments marketplace guide

"split_marketplace": [
  {
    "amount": { "currency": "BRL", "value": 500 },
    "recipient_id": "09d8bad7-4efe-47e2-b9ee-f4028460bab1",
    "type": "PURCHASE"
  },
  {
    "amount": { "currency": "BRL", "value": 500 },
    "recipient_id": "d94e02c1-cc47-4e60-a20a-2b17fe58992d",
    "type": "PURCHASE"
  }
]

• Receipt support for refund transactions
  Refund requests now accept a response_additional_data.receipt boolean and an optional receipt_language field. When set, a receipt URL is returned in payment.transaction.receipt_url after the refund is processed. See also: Refund payment reference

{
  "description": "Duplicate",
  "reason": "REQUESTED_BY_CUSTOMER",
  "merchant_reference": "AAB01-432245",
  "response_additional_data": {
    "receipt": true,
    "receipt_language": "ES"
  }
}

• Items data for subscriptions
  A new additional_data.order.items array is now available when creating a subscription, allowing you to pass item-level details (category, id, name, quantity, unit_amount) to providers. See also: Create subscription reference

"additional_data": {
  "order": {
    "items": [
      {
        "category": "art",
        "id": "AA01",
        "name": "Test item",
        "quantity": 1,
        "unit_amount": 10
      }
    ]
  }
}

• Payouts to vaulted tokens
  The Payouts API now supports sending payouts directly to enrolled credit or debit cards using a vaulted_token inside withdrawal_method. Provider support required. See also: Create payout reference

"withdrawal_method": {
  "type": "CARD",
  "provider_id": "UNLIMINT",
  "vaulted_token": "your-vaulted-token"
}

​

v2024-10

• Smart retry scheme for subscriptions
  Subscription declined transactions now support Smart Retries using machine learning to determine optimal retry timing. The retry schedule follows seven attempts over 96 hours. Configure via the Subscriptions dashboard. See also: Transaction retries guide

• Parent payment method type field
  A new parent_payment_method_type field is returned inside transactions.payment_method indicating the wallet provider (APPLE_PAY, GOOGLE_PAY, or CLICK_TO_PAY) used in a direct wallet integration. No integration changes required. See also: Payment object reference

"transactions": {
  "payment_method": {
    "vaulted_token": "29b44e45-57fe-41b0-81c8-586deeb699b2",
    "type": "CARD",
    "parent_payment_method_type": "CLICK_TO_PAY"
  }
}

• Connection ID in transaction data
  A new connection_data.id field is returned inside each transaction object, providing the unique identifier of the payment connection used to process the transaction. No integration changes required. See also: Payment object reference

"connection_data": {
  "id": "88292fd3-bf5b-4b23-bb95-7186ba4e7f88"
}

• Receipt support for cancel transactions
  Cancel requests now accept a response_additional_data.receipt boolean. When set, a receipt URL is returned in payment.transaction.receipt_url after the cancellation is processed. See also: Cancel payment reference

{
  "description": "Duplicate",
  "reason": "REQUESTED_BY_CUSTOMER",
  "merchant_reference": "AAB01-432245",
  "response_additional_data": {
    "receipt": true
  }
}

• Shipping object in payment request
  A new shipping object is available when creating a payment, supporting fields type, description, carrier, and deliver_at to specify shipment details. See also: Payment object reference

"shipping": {
  "type": "STANDARD",
  "description": "Test shipment",
  "carrier": "UPS",
  "deliver_at": "2024-09-17T20:43:54.786342Z"
}

​

v2024-09

• Payment link enrollment flow
  Payment links now support card enrollment on successful payment. Set one_time_use=true and vault_on_success=true when creating a payment link to generate a new vaulted_token for the customer upon payment success. See also: Enroll cards with payment links guide
• Split marketplace payments
  A new split_marketplace array is now available in the payment request, allowing merchants to divide a payment among multiple recipients with configurable amounts, types (PURCHASE, COMMISSION), and liability settings. Provider support required. See also: Split marketplace guide

"split_marketplace": [
  {
    "provider_recipient_id": "recipient_123",
    "type": "PURCHASE",
    "amount": { "value": 7500, "currency": "COP" },
    "liability": {
      "processing_fee": "MERCHANT",
      "chargebacks": false
    }
  },
  {
    "provider_recipient_id": "recipient_456",
    "type": "COMMISSION",
    "amount": { "percentage": 30, "currency": "COP" },
    "liability": {
      "processing_fee": "RECIPIENT",
      "chargebacks": true
    }
  }
]

​

v2024-08

• Subscription agreement ID field
  A new subscription_agreement_id field is available inside payment_method.detail.card.stored_credentials, required by certain markets and processors (e.g., Mexico) to include the agreement ID with the customer in subscription-related payments. See also: Stored credentials guide

"payment_method": {
  "type": "CARD",
  "vaulted_token": "eb8caa17-6407-457b-960e-125d8d7a90c1",
  "detail": {
    "card": {
      "stored_credentials": {
        "reason": "CARD_ON_FILE",
        "usage": "USED",
        "subscription_agreement_id": "AA0001"
      }
    }
  }
}

• Referenced payouts from transactions
  Payouts to card payment methods now support a original_transaction_id field inside withdrawal_method, enabling merchants to initiate a payout using card data from a prior transaction without needing PCI compliance. See also: Payouts guide

"withdrawal_method": {
  "type": "STP_PAYOUT",
  "provider_id": "STP",
  "original_transaction_id": "9104911d-5df9-429e-8488-ad41abea1a4b"
}

• Currency conversion in payments
  A new currency_conversion object is available inside the amount struct, allowing you to pass provider_currency_conversion_id, cardholder_currency, and cardholder_amount for dual-currency settlement. Contact your technical account manager to enable. See also: Currency conversion guide

"amount": {
  "currency": "COP",
  "value": 5000,
  "currency_conversion": {
    "provider_currency_conversion_id": "AAA01SADOIAJSDLAKSJM",
    "cardholder_currency": "ARS",
    "cardholder_amount": 1146.55
  }
}

• ISO 8583 response code and message
  Two new fields, iso8583_response_code and iso8583_response_message, are now returned inside transactions.provider_data, providing the direct ISO 8583 response from the provider. ABECS codes are also surfaced in these fields for Brazilian providers. See also: Payment object reference

"provider_data": {
  "id": "ADYEN",
  "transaction_id": "FLX4WSXF7SFZDV65",
  "iso8583_response_code": "05",
  "iso8583_response_message": "Approved or completed successfully"
}

• Cancel or refund payment by payment ID
  A new endpoint allows you to cancel or refund a payment by providing only the payment_id, without needing the transaction_id. The existing transaction-level endpoint remains available. See also: Cancel or refund payment reference

​

v2024-07

• Wallet cryptogram for native pay
  A new cryptogram field is available inside payment_method.detail.wallet when creating a payment, enabling direct Apple Pay and Google Pay API integrations without using the Yuno SDK. See also: Apple Pay direct integration guide
• Taxes array in order data
  A new taxes array of objects is available inside additional_data.order, supporting multiple tax lines per payment. The prior top-level tax object remains supported but the new array is recommended for better tax management. See also: Payment amount details guide

• Simplified mode for refund retries
  The simplified_mode: true flag is now supported in refund requests. Yuno will return a DECLINED status and automatically retry the refund up to five times within 24 hours, keeping the payment in PENDING/RETRY_IN_PROCESS status. See also: Transaction retries guide

{
  "simplified_mode": true,
  "reason": "REQUESTED_BY_CUSTOMER",
  "merchant_reference": "AA01"
}

​

v2024-06

• Payouts product launch
  Yuno Payouts is now available as a new API product for sending funds to beneficiaries (users, merchants, providers, customers) across banks, cards, and wallets through multiple providers. Refer to the payouts documentation to get started. See also: Payouts guide

• Payment method fingerprint field
  A new fingerprint field is returned in the payment method object and in the payment response for card transactions. It uniquely identifies a card across multiple vaulted_tokens within your organization. See also: Enroll payment methods guide

​

v2024-05

• Simplified mode for capture retries
  A new simplified_mode boolean is available in capture requests. When set to true, Yuno returns a SUCCEEDED status immediately and automatically retries failed transactions up to five times within a 24-hour period. See also: Transaction retries guide

{
  "amount": { "currency": "COP", "value": "5000" },
  "simplified_mode": true,
  "reason": "PRODUCT_CONFIRMED",
  "merchant_reference": "AA01"
}

• Benefit type field for Pluxee payments
  A new benefity_type field has been added to the payment object for the Pluxee payment method in Chile. Required when using the DIRECT workflow. See also: Payment object reference

​

v2024-04

• Routing rules in payment response
  A new routing_rules object is now returned in the payment response, containing a condition sub-object with the id, name, and description of the routing rule applied during payment creation. No integration changes required. See also: Payment object reference

"routing_rules": {
  "condition": {
    "id": 76152,
    "name": "PAYMENTS_COLOMBIA",
    "description": "This condition is set for payments made only in Colombia"
  }
}

​

v2024-03

• Merchant customer created at field
  A new merchant_customer_created_at field (ISO 8601 format) is available in the Customer and customer_payer objects, representing the date the customer registered on the merchant platform. See also: Customer object reference
• Installments plan in checkout session
  A new installments.plan array and installments.plan_id field are available in the checkout session object, allowing you to specify a custom installments plan per session. If omitted, the account-level plan is used. See also: Create checkout session reference
• Callback URL for payment links
  A new callback_url field is available when creating a payment link, specifying the URL the customer is redirected to after completing payment. See also: Payment link object reference

​

v2024-02

• Neighborhood field in address objects
  A new neighborhood field (3–255 characters) has been added to shipping_address and billing_address in the Customer object. See also: Customer object reference

• Transactions history array
  A new transactions_history array is now returned in the payment object, listing all transactions associated with a payment including those across multiple provider routes. See also: Payment object reference
• Tip amount field in order data
  A new tip_amount field is available inside additional_data.order. This is informational only — the tip amount is already included in the total transaction value and is not added separately. See also: Payment amount details guide

"additional_data": {
  "order": {
    "tip_amount": 50.00
  }
}

• In-progress capture error message
  The API now returns a specific error response when a capture is attempted while another capture is already in progress: INVALID_STATUS with message “Invalid transaction status. Transaction already in progress”. No integration changes required. See also: Payment object reference

{
  "code": "INVALID_STATUS",
  "messages": [
    "Invalid transaction status. Transaction already in progress"
  ]
}

​

v2024-01

• Provider data fields in transaction
  Three new fields are now returned inside transactions.provider_data: response_code (provider outcome code), third_party_account_id (processor account ID), and third_party_transaction_id (processor transaction ID). No integration changes required. See also: Payment object reference

• Stored credentials support
  Yuno now supports Visa and Mastercard stored credentials rules, allowing merchants to mark payments as Customer Initiated Transactions (CIT) or Merchant Initiated Transactions (MIT) via the stored_credentials struct inside payment_method.detail.card. See also: Stored credentials guide