> ## Documentation Index
> Fetch the complete documentation index at: https://yuno-3979e326-fix-create-subscription-card-usage.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# API Changelog

> Latest updates to the Yuno Payments API and platform features

export const ChangelogBadge = ({type}) => {
  const types = {
    added: {
      color: 'success',
      label: 'ADDED'
    },
    changed: {
      color: 'warning',
      label: 'CHANGED'
    },
    deprecated: {
      color: 'alert',
      label: 'DEPRECATED'
    },
    removed: {
      color: 'error',
      label: 'REMOVED'
    },
    fixed: {
      color: 'info',
      label: 'FIXED'
    },
    security: {
      color: 'security',
      label: 'SECURITY'
    },
    breaking: {
      color: 'breaking',
      label: 'BREAKING'
    }
  };
  const config = types[type.toLowerCase()] || ({
    color: 'secondary',
    label: type.toUpperCase()
  });
  return <span className={`status-badge status-${config.color}`}>
      {config.label}
    </span>;
};

## v2025-06

*June 30, 2025*

* <ChangelogBadge type="changed" /> **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](/reference/create-customer)*

**Security**

* <ChangelogBadge type="added" /> **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](/docs/sca-exemptions)*

**Payments**

* <ChangelogBadge type="added" /> **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](/reference/create-payment)*

* <ChangelogBadge type="added" /> **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](/reference/create-payment)*

* <ChangelogBadge type="added" /> **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](/reference/create-payment)*

## v2025-05

*May 31, 2025*

**Security**

* <ChangelogBadge type="changed" /> **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](/docs/network-tokens)*

**Subscriptions**

* <ChangelogBadge type="added" /> **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](/docs/subscriptions)*

**Payments**

* <ChangelogBadge type="added" /> **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](/reference/create-payment)*

<Accordion title="expirates_at in wallet response">
  ```json theme={null}
  "payment_method": {
    "type": "NU_PAY",
    "payment_method_detail": {
      "wallet": {
        "expirates_at": "2025-05-14T15:06:48.383418Z"
      }
    }
  }
  ```
</Accordion>

* <ChangelogBadge type="added" /> **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](/reference/create-payment)*

<Accordion title="geolocation in customer_payer">
  ```json theme={null}
  "customer_payer": {
    "id": "b080db73-b12d-4710-a604-d659bce26f01",
    "geolocation": {
      "latitude": "-34.4720",
      "longitude": "-58.5300"
    }
  }
  ```
</Accordion>

* <ChangelogBadge type="added" /> **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](/reference/cancel-payment)*

**Webhooks**

* <ChangelogBadge type="added" /> **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](/docs/configure-webhooks)*

## v2025-04

*April 30, 2025*

**Security**

* <ChangelogBadge type="changed" /> **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](/docs/security-and-compliance/3d-secure)*

**Payments**

* <ChangelogBadge type="added" /> **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](/reference/create-payment)*

<Accordion title="Airline legs with new fields">
  ```json theme={null}
  "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"
          }
        }
      ]
    }
  }
  ```
</Accordion>

## v2025-03

*March 31, 2025*

**Payments**

* <ChangelogBadge type="added" /> **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](/docs/payment-amount-details#discounts)*

<Accordion title="discounts in additional_data.order">
  ```json theme={null}
  "additional_data": {
    "order": {
      "discounts": [
        {
          "id": "XYZ",
          "name": "Offer",
          "unit_amount": "100"
        }
      ]
    }
  }
  ```
</Accordion>

* <ChangelogBadge type="added" /> **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](/reference/the-payment-object)*

<Accordion title="monitors in routing_rules response">
  ```json theme={null}
  "routing_rules": {
    "smart_routing": false,
    "monitors": true,
    "condition": {
      "id": 133892,
      "name": null,
      "description": null
    }
  }
  ```
</Accordion>

**Refunds**

* <ChangelogBadge type="added" /> **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](/reference/refund-payment)*

<Accordion title="customer_payer in refund request">
  ```json theme={null}
  {
    "description": "Duplicate",
    "reason": "REQUESTED_BY_CUSTOMER",
    "merchant_reference": "AAB01-432245",
    "customer_payer": {
      "document": {
        "document_type": "DNI",
        "document_number": "38919283"
      }
    }
  }
  ```
</Accordion>

## v2025-02

*February 28, 2025*

**Webhooks**

* <ChangelogBadge type="added" /> **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](/docs/configure-webhooks)*

* <ChangelogBadge type="added" /> **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](/docs/configure-webhooks)*

## v2025-01

*January 31, 2025*

**Payments**

* <ChangelogBadge type="added" /> **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](/reference/payment)*

<Accordion title="tickets in additional_data.order">
  ```json theme={null}
  "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"
          }
        }
      ]
    }
  }
  ```
</Accordion>

**Subscriptions**

* <ChangelogBadge type="added" /> **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](/reference/create-subscription)*

<Accordion title="initial_payment_validation in subscription">
  ```json theme={null}
  {
    "initial_payment_validation": true
  }
  ```
</Accordion>

## v2024-12

*December 31, 2024*

**Payments**

* <ChangelogBadge type="added" /> **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](/reference/create-payment)*

<Accordion title="Specify DEBIT or CREDIT for vaulted token">
  ```json theme={null}
  "payment_method": {
    "type": "CARD",
    "vaulted_token": "e2961d37-9898-4bac-8408-cc9f02c11cc2",
    "detail": {
      "card": {
        "card_data": {
          "type": "DEBIT"
        }
      }
    }
  }
  ```
</Accordion>

* <ChangelogBadge type="added" /> **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](/docs/account-funding-transactions-afts)*

<Accordion title="account_funding in additional_data">
  ```json theme={null}
  "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"
        }
      }
    }
  }
  ```
</Accordion>

* <ChangelogBadge type="added" /> **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](/docs/stored-credentials)*

<Accordion title="network_transaction_id in stored_credentials">
  ```json theme={null}
  "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"
        }
      }
    }
  }
  ```
</Accordion>

* <ChangelogBadge type="added" /> **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](/reference/create-payment)*

<Accordion title="smart_routing in routing_rules response">
  ```json theme={null}
  "routing_rules": {
    "smart_routing": false,
    "condition": {
      "id": 133892,
      "name": null,
      "description": null
    }
  }
  ```
</Accordion>

**Subscriptions**

* <ChangelogBadge type="added" /> **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](/reference/create-subscription)*

<Accordion title="trial_period in subscription request">
  ```json theme={null}
  "trial_period": {
    "billing_cycles": "1",
    "amount": {
      "currency": "COP",
      "value": 2500
    }
  }
  ```
</Accordion>

## v2024-11

*November 30, 2024*

**Payments**

* <ChangelogBadge type="added" /> **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](/reference/the-payment-object)*

<Accordion title="expiration_month and expiration_year in card_data">
  ```json theme={null}
  "card_data": {
    "holder_name": "Paco",
    "iin": "48710499",
    "brand": "VISA",
    "fingerprint": "71000db4-f8e7-4ea0-a2cc-9d9ebb76a955",
    "expiration_month": 3,
    "expiration_year": 30
  }
  ```
</Accordion>

* <ChangelogBadge type="added" /> **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](/docs/payment-features/split-payments-marketplace)*

<Accordion title="Use recipient_id in split_marketplace">
  ```json theme={null}
  "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"
    }
  ]
  ```
</Accordion>

**Refunds**

* <ChangelogBadge type="added" /> **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](/reference/refund-payment)*

<Accordion title="Request a receipt on refund">
  ```json theme={null}
  {
    "description": "Duplicate",
    "reason": "REQUESTED_BY_CUSTOMER",
    "merchant_reference": "AAB01-432245",
    "response_additional_data": {
      "receipt": true,
      "receipt_language": "ES"
    }
  }
  ```
</Accordion>

**Subscriptions**

* <ChangelogBadge type="added" /> **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](/reference/create-subscription)*

<Accordion title="items in subscription additional_data">
  ```json theme={null}
  "additional_data": {
    "order": {
      "items": [
        {
          "category": "art",
          "id": "AA01",
          "name": "Test item",
          "quantity": 1,
          "unit_amount": 10
        }
      ]
    }
  }
  ```
</Accordion>

**Payouts**

* <ChangelogBadge type="added" /> **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](/reference/create-payout)*

<Accordion title="Payout to an enrolled card">
  ```json theme={null}
  "withdrawal_method": {
    "type": "CARD",
    "provider_id": "UNLIMINT",
    "vaulted_token": "your-vaulted-token"
  }
  ```
</Accordion>

## v2024-10

*October 31, 2024*

**Subscriptions**

* <ChangelogBadge type="added" /> **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](/docs/payment-features/transaction-retries)*

**Payments**

* <ChangelogBadge type="added" /> **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](/reference/the-payment-object)*

<Accordion title="parent_payment_method_type in transaction">
  ```json theme={null}
  "transactions": {
    "payment_method": {
      "vaulted_token": "29b44e45-57fe-41b0-81c8-586deeb699b2",
      "type": "CARD",
      "parent_payment_method_type": "CLICK_TO_PAY"
    }
  }
  ```
</Accordion>

* <ChangelogBadge type="added" /> **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](/reference/the-payment-object)*

<Accordion title="connection_data.id in transaction">
  ```json theme={null}
  "connection_data": {
    "id": "88292fd3-bf5b-4b23-bb95-7186ba4e7f88"
  }
  ```
</Accordion>

* <ChangelogBadge type="added" /> **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](/reference/cancel-payment)*

<Accordion title="Request a receipt on cancel">
  ```json theme={null}
  {
    "description": "Duplicate",
    "reason": "REQUESTED_BY_CUSTOMER",
    "merchant_reference": "AAB01-432245",
    "response_additional_data": {
      "receipt": true
    }
  }
  ```
</Accordion>

* <ChangelogBadge type="added" /> **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](/reference/the-payment-object)*

<Accordion title="shipping in payment request">
  ```json theme={null}
  "shipping": {
    "type": "STANDARD",
    "description": "Test shipment",
    "carrier": "UPS",
    "deliver_at": "2024-09-17T20:43:54.786342Z"
  }
  ```
</Accordion>

## v2024-09

*September 30, 2024*

**Payments**

* <ChangelogBadge type="added" /> **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](/docs/enroll-cards-with-payment-link)*

* <ChangelogBadge type="added" /> **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](/docs/split-payments-marketplace)*

<Accordion title="split_marketplace in payment request">
  ```json theme={null}
  "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
      }
    }
  ]
  ```
</Accordion>

## v2024-08

*August 31, 2024*

**Subscriptions**

* <ChangelogBadge type="added" /> **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](/docs/stored-credentials#subscription-agreement)*

<Accordion title="subscription_agreement_id in stored_credentials">
  ```json theme={null}
  "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"
        }
      }
    }
  }
  ```
</Accordion>

**Payouts**

* <ChangelogBadge type="added" /> **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](/docs/payouts)*

<Accordion title="Payout referencing an original transaction">
  ```json theme={null}
  "withdrawal_method": {
    "type": "STP_PAYOUT",
    "provider_id": "STP",
    "original_transaction_id": "9104911d-5df9-429e-8488-ad41abea1a4b"
  }
  ```
</Accordion>

**Payments**

* <ChangelogBadge type="added" /> **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](/docs/currency-conversion)*

<Accordion title="currency_conversion in amount">
  ```json theme={null}
  "amount": {
    "currency": "COP",
    "value": 5000,
    "currency_conversion": {
      "provider_currency_conversion_id": "AAA01SADOIAJSDLAKSJM",
      "cardholder_currency": "ARS",
      "cardholder_amount": 1146.55
    }
  }
  ```
</Accordion>

* <ChangelogBadge type="added" /> **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](/reference/the-payment-object)*

<Accordion title="iso8583 fields in provider_data">
  ```json theme={null}
  "provider_data": {
    "id": "ADYEN",
    "transaction_id": "FLX4WSXF7SFZDV65",
    "iso8583_response_code": "05",
    "iso8583_response_message": "Approved or completed successfully"
  }
  ```
</Accordion>

* <ChangelogBadge type="added" /> **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](/reference/cancel-or-refund-a-payment)*

## v2024-07

*July 31, 2024*

**Payments**

* <ChangelogBadge type="added" /> **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](/docs/apple-pay-direct-integration)*

* <ChangelogBadge type="added" /> **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](/docs/payment-amount-details#taxes)*

**Refunds**

* <ChangelogBadge type="added" /> **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](/docs/transaction-retries)*

<Accordion title="simplified_mode in refund request">
  ```json theme={null}
  {
    "simplified_mode": true,
    "reason": "REQUESTED_BY_CUSTOMER",
    "merchant_reference": "AA01"
  }
  ```
</Accordion>

## v2024-06

*June 30, 2024*

**Payouts**

* <ChangelogBadge type="added" /> **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](/docs/payouts)*

**Payments**

* <ChangelogBadge type="added" /> **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](/docs/enroll-payment-methods#step-5-retrieve-payment-methods)*

## v2024-05

*May 31, 2024*

**Payments**

* <ChangelogBadge type="added" /> **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](/docs/transaction-retries)*

<Accordion title="simplified_mode in capture request">
  ```json theme={null}
  {
    "amount": { "currency": "COP", "value": "5000" },
    "simplified_mode": true,
    "reason": "PRODUCT_CONFIRMED",
    "merchant_reference": "AA01"
  }
  ```
</Accordion>

* <ChangelogBadge type="added" /> **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](/reference/the-payment-object)*

## v2024-04

*April 30, 2024*

* <ChangelogBadge type="added" /> **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](/reference/the-payment-object)*

<Accordion title="routing_rules in payment response">
  ```json theme={null}
  "routing_rules": {
    "condition": {
      "id": 76152,
      "name": "PAYMENTS_COLOMBIA",
      "description": "This condition is set for payments made only in Colombia"
    }
  }
  ```
</Accordion>

## v2024-03

*March 31, 2024*

**Payments**

* <ChangelogBadge type="added" /> **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](/reference/the-customer-object)*

* <ChangelogBadge type="added" /> **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](/reference/create-checkout-session)*

* <ChangelogBadge type="added" /> **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](/reference/the-payment-link-object)*

## v2024-02

*February 29, 2024*

* <ChangelogBadge type="added" /> **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](/reference/the-customer-object)*

**Payments**

* <ChangelogBadge type="added" /> **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](/reference/the-payment-object)*

* <ChangelogBadge type="added" /> **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](/docs/payment-amount-details)*

<Accordion title="tip_amount in additional_data.order">
  ```json theme={null}
  "additional_data": {
    "order": {
      "tip_amount": 50.00
    }
  }
  ```
</Accordion>

* <ChangelogBadge type="added" /> **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](/reference/the-payment-object)*

<Accordion title="INVALID_STATUS error response">
  ```json theme={null}
  {
    "code": "INVALID_STATUS",
    "messages": [
      "Invalid transaction status. Transaction already in progress"
    ]
  }
  ```
</Accordion>

## v2024-01

*January 31, 2024*

* <ChangelogBadge type="added" /> **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](/reference/the-payment-object)*

**Security**

* <ChangelogBadge type="added" /> **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](/docs/stored-credentials)*