This page documents a legacy SDK. Starting a new integration? Use the Yuno SDK. Already on a legacy SDK? Follow the migration guide.The new Yuno SDK (Web v2.x, iOS v3.x, Android v3.x, React Native v2.x) replaces the Full, Lite, Seamless, Render, Headless, and Secure Fields SDKs with one API across every platform. Legacy SDKs remain supported side by side during the transition and are scheduled for deprecation in 2027. Contact your Account Manager for migration planning.
Yuno’s Headless SDK lets you create payments. When using the Headless SDK, note that you will need to request and send via API all the mandatory fields the payment provider requires. These fields are needed to generate the payment in their API. Yuno’s Headless SDK enables you to create payments in two different scenarios:
- Create a One-Time Use Token using credit card information, then create a payment.
- Create a One-Time Use Token using a
vaulted_tokenfrom a previously enrolled credit card, then create a payment.
Step 1: Include the library in your project
Before proceeding with the Headless SDK implementation, see the SDK Integration Overview for detailed instructions on how to properly integrate the SDK into your project. The integration guide provides three flexible methods:- Direct HTML script inclusion
- Dynamic JavaScript injection
- NPM module installation
TypeScript LibraryIf you are using TypeScript, Yuno provides a library that you can use to see all available methods in the Yuno Web SDK.
Step 2: Initialize Headless SDK with the public key
In your JavaScript app, create an instance of theYuno class by providing a valid PUBLIC_API_KEY.
CredentialsSee the credentials page for more information: /reference/getting-started/authentication
Step 3: Start the checkout process
Next, you will start the checkout process using theapiClientPayment function, providing the necessary configuration parameters.
Parameters
Configure the payment with the following options:Preloading fraud fingerprints
If your account uses fraud screening with a provider whose fingerprinting script can take longer than the configured fraud timeout, callexecuteFraudCheck when the payment form renders, not at the moment your customer clicks “Pay.” Some providers’ fingerprinting scripts take longer than the timeout to load in certain regions. Calling apiClientPayment and generateToken back to back at click time can generate the one-time token before the fingerprint finishes loading. This means the token would be created without a device fingerprint.
Step 4: Generate token
After collecting all user information, you can start the payment. First, you need to create a one-time token (OTT) using the functionapiClientpayment.generateToken. As it is an asynchronous function, you can use try/catch to ensure you will correctly handle triggered errors. The following examples show different scenarios to create the one-time token:
- Example 1: Create a one-time token utilizing a card as the payment method and including all requisite card information.
- Example 2: Create a one-time token using the
vaulted_tokeninformation.
payment_method. See Split one payment across two cards.
Benefits of Using a Vaulted TokenWhen you use a vaulted token with the SDK, all the fraud information from the providers you configured in your card routing is collected. This information is attached to the one-time token. In addition, you can add installment information and a security code if the provider requires it.
Example 1
Parameters for Example 1
Example 2
Parameters for Example 2
The following code block shows the
apiClientPayment.generateToken function responses for both examples above:
Example 1
Example 2
Step 5: Create the Payment
After receiving the one-time token, you can create the payment using the Create Payment endpoint to get the final payment result. You will inform the one-time token received in Step 4 through the request’spayment_method.token parameter. The following code block shows a request example for creating a payment:
sdk_action_required parameter that defines if additional actions are necessary to conclude the payment:
- If your customer selects a synchronous payment method, the payment is completed instantly. In this scenario, the field
sdk_action_requiredin the API response will befalse, and the payment process concludes at this step. - When an additional interaction of the SDK is needed to complete the payment flow,
sdk_action_requiredwill betrue. If this is the case, you need to follow the instructions from Step 6.
Step 6: Get the 3DS challenge URL
As described on the 3DS Card Verification page, a payment with 3DS may require an additional challenge to check the customer’s identity. If an additional verification step is necessary related to a 3DS verification challenge, the response to the Create Payment endpoint will have the following information:- A
THREE_D_SECUREtransaction type. - Status equal to
PENDINGand sub status equal toWAITING_ADDITIONAL_STEP. - The
sdk_action_requiredset astrue.
getThreeDSecureChallenge function, providing the checkoutSession used to create the payment.
url will return null.
For a payment split across two cards, call this function once per card. See Run the 3DS challenge of each card.
In a web browser, you can open the URL in a new tab or an IFrame. To open the URL in an iframe, you must set the param embedded = true. If not, you can omit this parameter, whose default value is false. The following code block shows an example of displaying the 3DS challenge content in an IFrame:
redirect_url to complete the challenge. Once the customer successfully completes the 3DS challenge, they will be automatically redirected to the callback_url. You provided this callback_url when creating the checkout_session with the Create Checkout Session endpoint.
To complete the Headless SDK payment flow, you need to use Yuno Webhooks. Webhooks promptly notify you about the outcome of the 3DS challenge and the final payment status, ensuring you receive real-time updates on the progress of the payment transaction. In addition to the webhooks, you can retrieve the payment information using the Retrieve Payment by ID endpoint.
Step 7: Get payment actions
Sometimes the payment may require an extra action to continue the payment flow. To determine what action is needed, you should call thegetContinuePaymentAction method, providing the checkoutSession used to create the payment.
getContinuePaymentAction method returns a ContinuePaymentAction object. This object describes the specific action required to continue the payment flow, depending on the provider and the specific step required.
ContinuePaymentAction response structure
The response contains information about the type of action required and the necessary data to perform that action:
ContinuePaymentAction Fields
Provider Types and Actions
The following enums define the supported payment providers and possible actions:Provider Types and Actions Reference
Handling different action types
Based on theaction field in the response, you should handle each type of action accordingly:
REDIRECT_URL Action
When the action is REDIRECT_URL, you should redirect the user to the URL provided in data.redirect.init_url:
Other Action Types
Each action type requires specific handling based on the data provided:- PAYMENT_CODE: Display the payment code and reference to the user
- IMAGE: Show a QR code or other image to the user
- OTP: Present an OTP input form to the user
- SDK_PROVIDER: Initialize the specific provider’s SDK
- RENDER_IFRAME: Display an iframe with the provider’s interface
Payment Action HandlingThe specific implementation for handling each action type will depend on your application’s UI framework and requirements. Ensure you handle all possible action types that your configured payment providers might return.
Demo AppIn addition to the code examples provided, you can access the Demo App for a complete implementation of Yuno SDKs (clone from the repository).
Split one payment across two cards
From Web SDK 1.11.43,generateToken can create one token for a payment that two cards fund together. Each card pays its own part of the amount. The flow is headless only: there is no checkout UI for it. For enablement, statuses, reversals, operations and errors, see Pay with two cards.
VersionYou need Web SDK 1.11.43 or later. If you load the SDK from
https://sdk-web.y.uno/v1.11/main.js, you already get it. If you install it from npm, run npm install @yuno-payments/sdk-web@^9: the 9.x package loads the v1.11 line from the CDN, which serves 1.11.43 or later. Version 10.x of the package loads Web SDK v2.Generate one token for both cards
Passpayment_method as an array with exactly two items, one per card, instead of a single object. Each item takes the same fields as a single payment method (type, card or vaulted_token, customer, device_fingerprints, third_party_data) plus the amount that card pays. Send total next to payment_method: the payment is rejected later without it.
The SDK collects the fraud data and browser information for each item, as it does for a single card. When you pass an array, the function resolves to a single composite token:
generateToken behaves as before and returns the response shown in Step 4. Existing integrations do not change.
The SDK checks the array before it sends any request and throws an error that names the item at fault. Wrap the call in try/catch.
Create the payment
Create the payment from your server withPOST /v2/payments (https://api.y.uno/v2/payments in production, or https://api-sandbox.y.uno/v2/payments in sandbox). Use the same authentication headers as the other payment endpoints. The v1 Create Payment endpoint from Step 5 is for a token of one payment method; a composite token goes to POST /v2/payments.
To read the result for each card, call
GET /v2/payments/{payment_id} from your server with the same authentication headers. Its payment_method.payment_methods array has one entry per card, each with its sequence (the position of the card in the token), type, amount and transactions. A card has no status of its own: read the outcome of each card from its transactions, where the THREE_D_SECURE transaction of the card carries the result of its challenge. The payment-level status and sub_status sum up both cards. The v1 Retrieve Payment endpoint shows the payment as a whole, not each card. See Pay with two cards for the full response, the statuses and the operations, and the Retrieve Payment (two cards) reference.
Run the 3DS challenge of each card
When the cards need 3DS, callgetThreeDSecureChallenge once per card, in the order of the payment_method array. Render each URL it returns as described in Step 6, and wait for that challenge to finish before you call it again. Each call returns the challenge of the first card, in array order, that is still waiting for 3DS. A card that needs no challenge is skipped, so the next call already returns the next card that needs one. When no card is waiting for 3DS any more, the call resolves with url: null: that is the signal to stop, never a sign that one card was exempt. Yuno records the result of a challenge a few seconds after the customer completes it, so wait until the card’s THREE_D_SECURE transaction leaves PENDING (through your webhook or GET /v2/payments/{payment_id}) before you call getThreeDSecureChallenge for the next card; a call made before that can hand back the same card’s challenge again.
How Yuno processes the two cards
- A card that needs 3DS is charged as soon as its own challenge finishes. A card that needs no 3DS is charged when the payment is created.
- If the challenge of a card fails or its issuer declines it, the whole payment ends. Yuno reverses the charge of a card that was already charged and cancels the pending 3DS of the other card. Do not ask your customer to continue with the remaining card: start a new payment instead.
- The final payment has one entry per card in
payment_method.payment_methods, each with itssequence,type,amountandtransactions. There is no status per card: read each card’s outcome from its transactions. Read it from your webhooks or withGET /v2/payments/{payment_id}.