3DS sandbox simulator

Testing 3DS in sandbox has historically been a point of friction. Traditional simulators often rely on specific card numbers that can clash with BIN services or downstream PSP test cards, forcing merchants to choose between testing 3DS or testing their processor. This simulator decouples 3DS testing from external providers. By allowing triggers based on billing data (like a specific email address), you can easily automate a wide variety of test scenarios—from friction-free approvals to step-up challenges—without needing to manage complex sets of test card numbers.

A powerful new 3DS sandbox simulator allows you to mock 3D Secure responses in the sandbox environment without relying on external 3DS servers. 

A new set of API endpoints (/three-ds-scenarios) has been released to define, manage, and order custom rules for 3DS outcomes. Instead of relying solely on card numbers, you can now trigger specific 3DS scenarios based on various transaction properties:

• Buyer Details: Match on first name, last name, or email address.
• Transaction Data: Match on amount or external_identifier.
• Payment Data: Match on specific card numbers or BINs.

For every rule, you can specify the enrollment status and the specific authentication result. The simulator fully supports mocking the challenge handshake, ensuring a complete end-to-end integration test.

For more information, see the 3DS testing guide.

Availability and limitations

The 3DS sandbox simulator is available exclusively in the sandbox environment. These endpoints and rules do not function in production to ensure live transaction security. Please note the following current limitations:

• Hosted 3DS Flow Only: The simulator is currently optimised for use with the hosted 3DS implementation.
• Checkout Sessions Support: Support is not yet available for 3DS performed via Checkout Sessions (used by the Native Mobile SDK). This is because the native 3DS SDK requires specific, proprietary initialisation values to handle the native challenge flow that are not yet generated by the simulator.

Webhook retry improvements

Webhook delivery infrastructure has been enhanced with advanced isolation and retry capabilities to provide even greater reliability for mission-critical integrations. The retry logic has been refined to maintain delivery attempts over a 7-day window with intelligent exponential back-off. Enhanced queue management ensures webhook integrity is maintained even during extended endpoint maintenance or downtime.

Native 3DS for mobile

A major advancement in mobile payment capabilities has been introduced: native 3D Secure (3DS) support for Mobile SDKs, powered by an enhanced Checkout Sessions backend to modernise the 3DS experience:

• Native Mobile 3DS Integration: A native 3DS SDK has been integrated into native iOS and Android SDKs, allowing you to handle the 3DS challenge entirely within their native app UI, eliminating jarring web-view redirects.
• Checkout Sessions 3DS Extension: The Checkout Sessions API has been extended to support 3DS authentication independently of a transaction, with new internal endpoints providing the necessary data to kick off the 3DS flow directly on the client side.
• 3DS at Vaulting: You can now perform 3DS authentication at the time of vaulting a card, ensuring payment methods are authenticated and “transaction-ready” before a buyer even reaches the final checkout step.

Previously, 3DS on mobile relied on a “redirect-to-web” flow where users were forced into a web-view experience to complete their bank’s challenge. This created friction, inconsistent branding, and a disjointed user journey.By moving to a native 3DS flow, you can now provide a premium, high-conversion experience:​

This feature is available now for iOS and Android using the Swift and Kotlin SDKs. For more information, please refer to the Native 3DS guides.

Custom 3DS authentication amounts

You can now trigger a 3DS challenge for a total amount that exceeds the amount being authorised in the immediate transaction. This feature is often used in complex scenarios such as travel bookings where a customer’s total cart comprises multiple services - airfare, insurance, and airport transfers - that may need to be authorised separately against different merchant accounts (merchant IDs). Previously, merchants were forced to authenticate for the exact amount of the first transaction, which could lead to friction or re-authentication requirements for subsequent charges in the same session. With this update, you can authenticate the customer for the full cart total in one go. The resulting 3DS payload can then be applied to the first authorisation and safely reused for subsequent, smaller authorisations without requiring the customer to complete another challenge.

A new field, three_d_secure.amount, has been added to the /transactions request, allowing merchants to set the desired authentication value. The API returns the same field to confirm the amount used for the 3DS handshake. To ensure processing integrity, the system returns a client-side validation error (HTTP 4xx, for example 422 Unprocessable Entity) if a merchant attempts to authenticate for an amount lower than the transaction amount.

For more information, please refer to the 3DS documentation or contact a support representative.

Tokenise & store payment instruments via payment links

Payment Links have been significantly upgraded to support existing buyers, allowing you to send personalised payment links that can tokenise and store new payment methods directly to a buyer’s profile. Previously, Payment Links treated every customer as a “guest,” meaning buyer data had to be re-entered, and payment methods could not be saved for future transactions. This update unlocks a powerful new workflow, especially for subscription businesses and B2B merchants. You can now send a secure payment link to an existing customer not just to collect a one-time payment, but to capture and tokenise their card on file. This stored credential can then be used for seamless recurring billing or future one-click transactions, streamlining operations and improving the customer experience.

When creating a payment link, you can now specify a buyer_id or buyer_external_identifier, linking the transaction to an existing buyer record in your system.

New flags have been added to control the checkout experience, allowing you to specify if the “store card” option should be displayed and if specific billing address fields should be collected. When creating a payment link via the API, simply include the buyer_id and store flag. The generated link will take the user to a checkout page where they can pay and securely save their payment method to their profile.

Limitations

Please note that while this feature allows you to store a new payment method for an existing buyer, it does not yet support using previously stored payment methods for the transaction.

• Tokenisation Only: The payment link is designed to capture and tokenise a new card or payment method.
• No “Card on File” Selection: When the buyer opens the payment link, they will not see a list of their previously saved cards to choose from. They must enter payment details for the current transaction.

For more details, please refer to the documentation on Storing a Payment Method.

OAuth authentication for outbound webhooks

Support for OAuth authentication has been added to outbound webhooks, allowing merchants to securely deliver webhook events to systems that require OAuth-based authentication, such as Salesforce Revenue Cloud and Commerce Cloud. These enterprise platforms require OAuth tokens (Bearer tokens) for secure API communication. The OAUTH authentication supports both client_credentials and password grant types.

Configuration Fields: The webhook subscription setup now includes fields for:

• OAuth Token URL
• Client ID
• Client Secret
• Username (for password grant type)
• Password (for password grant type)

For more information, please refer to the webhook subscriptions documentation.

PayFac support

One of our backend gateways has been uplifted to provide dedicated support for Payment Facilitators (PayFacs), enabling proper aggregator and sub-merchant data handling. The connector now supports specific data fields required for the PayFac model, including the ability to send aggregatorInformation (such as Aggregator ID and Name) and detailed subMerchant information. 

For PayFacs, it is critical to correctly identify both the aggregator and the specific sub-merchant in the authorisation message to avoid compliance violations. To achieve this, the subMerchant information is managed directly in our backend to ensure that the correct PayFac and sub-merchant identities are consistently applied to every transaction.