Skip to main content

​
v2.6.0

November 6, 2026 Card Payments
  • Split One Payment Across Two Cards
    transaction.start([...]) takes an array of two card payment methods, each with its data.amount. The SDK creates one composite token, hands it to createPayment, runs each card’s 3DS in turn and sends one onStatus for the whole payment. With autoContinuePayment: false it stops after createPayment and you continue each card on your side. An invalid array rejects start() with INVALID_SPLIT_PAYMENT before any request.

​
v2.5.1

November 5, 2026 Checkout
  • Click to Pay enrolment works again when the shopper ticks the consent box
    In the Golden Flow card form, ticking “Save my information with Mastercard Click to Pay” showed a tick but the SDK received it as unticked, so the card was paid as a regular card and never enrolled in Click to Pay. “Remember me in this browser” and the mandate consent checkbox had the same problem. All three now report what the shopper sees.
  • Every Express Wallet You Switch On Now Renders As A Button
    With Horizontal express button stacking, every wallet whose Render as express button switch is on now renders as an express button, in your list order. Two rules used to pull wallets out of the row: Google Pay moved into the payment method list as soon as a second express wallet was on, and the row stopped at three buttons. Both are gone. Instead of dropping a wallet to make the rest fit, the row wraps: buttons keep an equal width, a row holds two on a phone and three when there is room, and a short last line is centred. The list order, the fallback to the list when a button does not load, and Vertical stacking behave as before. Merchants with two or more express wallets on will see Google Pay move from the list into the row, and merchants with more than three will see every wallet as a button over two or more lines.

​
v2.5.0

November 3, 2026 Checkout
  • Customer fields you already sent can be hidden, read-only or editable
    When the checkout session carries a customer and the Checkout Builder sets a state for a customer field, the form follows it: a hidden field is not shown and its value is still sent with the payment, a read-only field shows the value locked with a lock icon, and an editable field shows the value prefilled so the shopper can change it for this payment only. The SDK checks every hidden and read-only value with the same validation as the form: a value that fails it is shown editable with its error instead. When every field is hidden and valid, the form is skipped. If the country data the document, phone or address check needs cannot be loaded, those values are sent as they are. Without a state, without a customer or without a value, the fields behave as before.
  • Payment method list shows before the wallet buttons
    The payment method list now appears as soon as its payment methods render, without waiting for the Google Pay or Apple Pay buttons. A wallet that loads slowly or never loads no longer keeps the list behind a spinner for up to 5 seconds.
Apple Pay
  • Apple Pay loads sooner on the payment method list
    On the payment method list, the SDK now starts loading the Apple Pay button and Apple’s SDK as soon as the payment methods arrive, when Apple Pay is in the list, so the wallet buttons appear sooner. Nothing changes when Apple Pay is not offered or cannot be shown on the device.
Core SDK
  • Performance logs include time since SDK start
    Performance logs now include the time elapsed since the merchant called start(), so slow starts can be traced from the merchant’s first call.
  • SDK chunk download timings are reported as network metrics
    The SDK’s own lazy JS and CSS chunks now report their download timing as network metrics, with cache hits marked, so slow chunk loads show up in monitoring. Loading behaviour and timing are unchanged.
  • A performance log marks when all external buttons have rendered
    On the payment method list, the SDK logs once when every external button has finished loading, as Web SDK 1.11 does.
  • Unfinished chunk and wallet loads are logged when the page is hidden
    When the page is hidden while a chunk download or a wallet button is still loading, the SDK logs which loads were still open and for how long.

​
v2.4.0

November 3, 2026 Installments
  • Installment options are identified by plan id
    When two installment options shared the same number of installments, choosing the second one displayed the first. Options are now identified by their plan id, the selected plan id travels with the one-time token, and options with interest show an interest label. The onInstallmentSelected callback also receives the plan id (installmentId), the plan type, the rate and its financial costs (sdk-web-core 9.7.0).
Apple Pay
  • Apple Pay Button Outside Safari
    When Apple answers applePayUnsupported for the merchant identifier on a browser other than Safari, the SDK no longer hides the Apple Pay button on that answer alone: it now shows the button when canMakePayments() is true. Shoppers with no card in Wallet (paymentCredentialsUnavailable) still do not see it.

​
v2.3.0

October 29, 2026 Enrollment
  • Vaulted Token On The Enrollment onStatus Result
    When an enrollment ends with status ENROLLED, the result delivered to onStatus now carries vaultedToken with the token of the saved payment method, on every enrollment path. Other statuses and payment results do not carry the field.
Checkout
  • Saved PayPal accounts no longer show the “Unauthorized payment” banner
    Selecting a saved PayPal account whose instalment lookup returns no plans no longer shows NuPay’s “Unauthorized payment. There are no payment options available” banner. That banner is NuPay’s own rule and only applies to NuPay; a saved PayPal account with no plans pays as any other saved payment method.
Core SDK
  • Wallet views follow showStatusScreen
    The wallet views from getPaymentMethodsViews (Apple Pay, Google Pay, PayPal, Samsung Pay, Revolut Pay and PayPal Braintree) ignored the transaction’s showStatusScreen and always showed the SDK status screen, so with showStatusScreen: false onStatus waited for the shopper to click Continue. They now follow the transaction’s value, as the payment method list does: with false no status screen is shown and onStatus fires without it.
  • Mount Waits For Late Container
    When the element given in elementSelector is not in the page yet, the SDK now waits up to 3 seconds for it to appear before reporting ELEMENT_NOT_FOUND. Nothing changes when the element is already there.

​
v2.2.1

October 29, 2026 Core SDK
  • Wallet views follow showStatusScreen
    The wallet views from getPaymentMethodsViews (Apple Pay, Google Pay, PayPal, Samsung Pay, Revolut Pay and PayPal Braintree) ignored the transaction’s showStatusScreen and always showed the SDK status screen, so with showStatusScreen: false onStatus waited for the shopper to click Continue. They now follow the transaction’s value, as the payment method list does: with false no status screen is shown and onStatus fires without it.

​
v2.2.0

October 27, 2026 Core SDK
  • Redirect payment methods can open in a popup window
    When a provider connection is set to open its redirect in a popup, redirect-based payment methods open the provider in a window owned by the SDK instead of replacing the page. The merchant page stays mounted, and the SDK waits for the payment result, closes the window and fires the existing result callbacks, so no integration change is needed. The window opens at the step where the page used to be redirected; when the browser blocks it, the shopper gets a Continue to payment button. Connections without that setting keep the same-tab redirect.
  • A second transaction on the same page calls createPayment
    When a page ran a payment without createPayment and then a payment with createPayment using the SDK form, the second one created the payment itself and reported INVALID_CHECKOUT_SESSION. It now hands the token to createPayment, as it does when it is the first transaction on the page.
Fraud & Risk
  • Checkout.com Risk.js Device Session
    When a connection routed to Checkout.com has RISK_JS_ENABLED on, a PUBLIC_KEY and the merchant-specific sub-domain (MSSD), the SDK loads Checkout.com’s Risk.js in the background when the payment method mounts, publishes the device data and sends the returned deviceSessionId with the token and the payment as the CHECKOUT third-party session id, so Checkout.com can forward it as risk.device_session_id. It applies to every payment method routed to Checkout.com (cards, wallets and alternative payment methods). A failed script load, initialisation or publish never blocks the checkout: the entry is left empty, the failure is logged and the next request publishes again. Checkout.com keeps the device session for 20 minutes after it is issued, so a checkout that stays open longer than that pays without it.
Checkout
  • Card fields follow the Checkout Builder field colour
    When the Checkout Builder field colour is a colour other than white, the card number, expiration date and CVV fields and the address suggestions take it. Their text uses the Checkout Builder text colours and the borders and highlighted options are mixed from the text and field colours, so light text on a dark field stays readable. Nothing changes when the field colour is white or not set, and the styles passed in card.styles still apply on top (sdk-web-card 1.93.0).
  • More options spacing and divider
    In the Moon Active and folded layouts, the “More options” section has room above it, and it shows the “Or pay with” divider between the express buttons and the other payment methods.

​
v2.1.2

October 20, 2026 Transaction
  • Check whether a payment method will render before listing it
    New transaction.isPaymentMethodAvailable({ paymentMethodType }) resolves to true or false for any payment method type, with the same decision the SDK takes before it shows that method for the checkout session. Merchants that draw their own payment method list can call it and hide the methods that would not render.
Checkout
  • Payment method names keep the checkout font
    On host pages that set fonts on every element with a * rule, the payment method name and its Checkout Builder description in the radio list use the checkout font, weight and spacing.
  • Checkbox texts keep the checkout font
    On host pages that set fonts on every element with a * rule, the text of every checkbox (save card, save on success, billing same as shipping, mandate consent, Click to Pay sign-up and remember me) and of the Click to Pay radio options uses the checkout font, weight and spacing, like the payment method names (sdk-web-core 9.4.1).

​
v2.1.1

October 19, 2026 Card Payments
  • Card CVC Length Follows The Card Service
    The CVC field now enforces the security_code_length the card service returns for the card’s brand, for a new card and for a saved card. A 4-digit CVC typed on a 3-digit brand (Elo, Alelo, Edenred, Sodexo, VR) shows “Invalid security code” instead of being sent, which Adyen refused with code 103 “CVC is not the right length”. Amex keeps 4 digits, and brands with no length from the card service keep the previous 3-or-4 rule. Also picks up sdk-web-card 1.91.1: a card frame served from y.uno ignores an apiUrl or assetUrl outside the Yuno domain (sdk-web-card 1.92.0).

​
v2.1.0

October 17, 2026 Universal Web SDK
  • Czech Checkout Language
    Adds Czech (cs, cs-CZ) localization to the Universal Web SDK checkout, with the same copy as the Web SDK 1.11 release.
  • Payment method description from the Checkout Builder
    In the payment method list, the description the merchant sets for a payment method in the Checkout Builder (custom_description) shows as a grey second line under its name. The text is shown complete, wraps to as many lines as it needs and keeps its line breaks. Methods without a description, and saved cards or accounts, render as before. Same behavior as the Web SDK 1.11 release.
  • Fixed Loader After 3DS Setup
    When a payment ends at the 3DS setup step and the merchant handles the payment status (showStatusScreen: false), the SDK now hides its loader as soon as it delivers the result. Before, the loader stayed on screen for about a minute and then showed a “Transaction failed” error, even though the result had already reached the merchant. This affected 3DS-only authentications and card payments declined during 3DS authentication. Same behavior as the Web SDK 1.11 release.
  • EBANX Fingerprint No Longer Throws “invalid country”
    When EBANX device fingerprinting is configured and the countryCode passed to the SDK is a country EBANX does not support (for example US), the SDK no longer surfaces an uncaught invalid country error on every load. The error is now caught and logged, and the EBANX fingerprint is skipped for that load. Payments were not affected before or after this change.

​
v2.0.0

October 16, 2026
  • A new Yuno SDK
    Version 2.0.0 is the new Yuno SDK: one integration for payments and enrollment, with the same API on Web, iOS and Android. Load it from the CDN, create a transaction, and get the result in onStatus. It replaces the Full, Lite, Seamless, Render, Headless and Secure Fields integrations and isn’t compatible with 1.x.
    Migration guide → See also: Yuno SDK documentation · Get started
  • New global: SdkPayments
    The SDK is exposed as window.SdkPayments and initialized with SdkPayments.initialize (previously window.Yuno). See also: Get started
  • Previous SDK supported until 2027
    The 1.x SDK (Full, Lite, Seamless, Render, Headless and Secure Fields) stays supported side by side with the new Yuno SDK during the transition. Its deprecation is scheduled for 2027. Contact your Account Manager to plan the migration.