Skip to main content
A split payment lets the shopper fund one order with two cards. Each card pays its own part of the total, you create one payment, and you receive one result. The method is start on every platform. For a split payment it receives an array of payment methods instead of one. The SDK creates one composite token, hands it to createPayment, runs the 3DS of each card and reports the outcome in onStatus. To divide a payment among marketplace recipients, see Split payments marketplace instead.

Availability

Before you start

  • Ask Yuno to enable it. Split payment is enabled per account. Without it, the token request fails with SPLIT_NOT_ENABLED.
  • Create the checkout session with the full amount. Use the total of the order and the default SDK_CHECKOUT workflow.
  • Override createPayment. You create the payment from your backend. See Create the payment.
  • Collect the card data in your own UI. Pass it in the object. The flow does not mount an SDK form or a payment methods list for the cards.
  • Pass each amount with the decimals of its currency. The SDK sends value as you give it, and the backend rejects extra decimals with AMOUNT_PRECISION.

Build the object

You build the same payment method object a one-card payment uses, once per card, and pass the two of them to start as an array. Each one adds the amount that card pays.

Rules for the items

  • Number of items: two, one per card.
  • Order: the first item is charged and authenticated first, then the second.
  • amount: required on every item, with currency and value.
  • Card data: every item carries a card or a vaulted token. The backend rejects an item with neither or with both.
  • Same card twice: not allowed. The SDK compares the card numbers and the vaulted tokens.
  • Currency: the same on every item, and the currency of the checkout session. The SDK checks the items against each other and the backend checks them against the session.
  • Sum of the amounts: must equal the amount of the checkout session. The backend validates it.

Complete example

Build the object, start the payment, create it in createPayment and receive the result in onStatus. This example splits a checkout session of 300 BRL into 200 BRL on a new card and 100 BRL on a vaulted card.

Create the payment

The token you receive in createPayment is one composite token for both cards. It carries token, checkout_session and expires_at. Read it from the token key. From your backend, send it to POST /v2/payments with workflow: "SDK_CHECKOUT", as payment_method.token.
POST /v1/payments rejects a composite token. Use POST /v2/payments.
The request, its fields and the response are in Pay with two cards, under the SDK_CHECKOUT example, and in the Create Payment (two cards) reference.

Receive the result

You receive the result in onStatus, at payment level. There is no callback per card. The SDK runs card 1 and then card 2. If card 1 fails, card 2 does not start and onStatus reports the status of the payment. If card 2 fails after card 1 was authorized, what happens to card 1 is handled on the backend. The payment response on your server shows the final state of each card: see Pay with two cards. On iOS, also from React Native, onStatus can report a non-final PENDING first, as for any payment. See onStatus, and confirm the outcome on your server before you fulfill the order.

Errors

SDK validations

The SDK checks the shape of the array before it requests the token, so an invalid array sends no request. The code is INVALID_SPLIT_PAYMENT and the message is in English. The message is for your developers: do not show it to the shopper. The SDK checks, in this order, that:
  • The array has two items.
  • Every item has an amount with a value greater than 0 and a currency.
  • Every item has the same currency as the first one.
  • No card or vaulted token appears twice.
The message names the item that failed. Everything else, such as the payment method type, an item with neither a card nor a vaulted token, the sum of the amounts and the currency of the session, is validated by the backend with the codes in Backend errors.

Where the array is not available

The array is for payment transactions. On an enrollment transaction (customerSession):

Backend errors

The backend validates the composite token request. When it rejects the request, onStatus receives status: "INTERNAL_ERROR" with message.source backend and no token reaches createPayment.