3DS sandbox simulator
A powerful new 3DS sandbox simulator allows merchants to mock 3D Secure responses in the sandbox environment without relying on external 3DS servers.What’s new?
- Mock 3DS API Endpoints: A new set of API endpoints (
/three-ds-scenarios) allow merchants to define, manage, and order custom rules for 3DS outcomes. - Flexible Condition Matching: Instead of relying solely on card numbers, merchants 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.
- Custom Outcomes: For every rule, merchants can specify the enrollment status and the specific authentication result (for example, Y for successful, C for challenge required).
- Challenge Flow Support: The simulator fully supports mocking the challenge handshake, ensuring a complete end-to-end integration test.
Why it matters
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), merchants 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.How it works
The simulator operates on a rule-based logic within the Gr4vy sandbox:- Register Rules: Use the
/three-ds-scenariosendpoint to register a rule. For example, you could create a rule where any transaction with the email[email protected]triggers a 3DS challenge. - Process Transaction: When a transaction is processed in sandbox, Gr4vy checks for any matching mock rules.
- Simulated Response: If a match is found, the simulator generates the mock 3DS data (including mock CAVV and ECI) and returns it. If no rule matches, the system falls back to the default sandbox behavior.
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 optimized 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 initialization values to handle the native challenge flow that are not yet generated by the simulator.
New connector: Ecommpay (card)
The connector ecosystem has expanded with the addition of Ecommpay, a leading international payment service provider. This new connector enables merchants to process global card payments through Ecommpay’s robust gateway.What’s new?
- Ecommpay Card Support: Merchants can now process credit and debit card transactions directly through Ecommpay using their existing credentials.
- Full Transaction Lifecycle: The connector supports the complete range of card operations, including authorizations, captures (delayed and partial), voids, and refunds.
- Advanced Data Support: To meet the needs of travel and hospitality merchants, the connector includes support for airline-specific data and cart items. This ensures that detailed transaction information is passed through to the processor for better risk management and reporting.
- Instrument Flexibility: In addition to standard PAN transactions, the connector supports modern payment instruments including Network Tokens, Apple Pay, and Click to Pay.
- Recurring Payments: Support for recurring payment flags is included, enabling merchants to manage subscription-based or installment payment flows seamlessly.
Why it matters
This connector was developed to support the travel and hospitality industry’s payment processing needs. Given the complexities of this industry, having a connector that natively handles airline data and recurring flags is essential for maintaining high authorization rates and accurate financial records.The Ecommpay connector meets the high standards required for large-scale airline operations and is now available to all merchants looking to leverage Ecommpay’s global reach and specialized features.How it works
To use this connector, merchants can select Ecommpay from the connector list in the Gr4vy dashboard. Once the required credentials (available via the Ecommpay merchant dashboard) are entered, transactions can be routed to Ecommpay using standard routing rules. The connector also supports webhooks for asynchronous updates, ensuring that transaction states remain synchronized across both platforms.Webhook retry improvements
Webhook delivery infrastructure has been enhanced with advanced isolation and retry capabilities to provide even greater reliability for mission-critical integrations.What’s new?
- Enhanced Isolation: Webhook endpoints now benefit from advanced isolation architecture, ensuring optimal delivery performance at scale.
- Optimized Retries: Refined retry logic maintains delivery attempts over a 7-day window with intelligent exponential back-off.
- Zero Data Loss: Enhanced queue management ensures webhook integrity is maintained even during extended endpoint maintenance or downtime.
Why it matters
Webhooks are the backbone of asynchronous payment processing. This infrastructure enhancement ensures:- Consistent Performance: The webhook endpoints receive notifications with consistent, predictable delivery performance.
- Automatic Recovery: Failed deliveries are intelligently retried without any manual intervention required.
- Scale with Confidence: Build robust integrations knowing the webhook infrastructure can handle high volume and complex delivery scenarios.
How it works
The enhanced infrastructure automatically manages webhook delivery with intelligent isolation and retry scheduling. Each endpoint operates independently with optimized delivery queues, ensuring reliable notification delivery even during peak transaction volumes.Transaction search by buyer external ID
The search feature within the Gr4vy Dashboard has been enhanced to allow merchants to locate transactions using a buyer’s external identifier.What’s new?
- Expanded Search Index: The transaction search index now includes the
buyer.external_identifierfield. - Unified Search Experience: Merchants can now enter this external system ID directly into the main search box in the Transactions dashboard to find the associated records.
Why it matters
This update was developed to support merchants who often rely on external system IDs to manage their support and operational workflows.Previously, locating a specific transaction using an identifier from a third-party CRM or internal database required manual cross-referencing or technical intervention. By indexing thebuyer.external_identifier, support teams can now immediately pull up transactions using the IDs they are already working with, significantly reducing friction and speeding up resolution times.How it works
No configuration changes are required. When a merchant enters a string into the Transaction search box, the system automatically checks for matches against thebuyer.external_identifier in addition to existing searchable fields like transaction ID or buyer name. This ensures that any transaction associated with a buyer who has an external ID is easily discoverable.Payment lifecycle graph
A new Sankey graph visualization has been introduced to the dashboard homepage. This dynamic chart provides a complete view of the payment lifecycle throughout the system, complementing the recent homepage updates.What’s new?
The Sankey graph is now integrated directly into the dashboard homepage, providing a dynamic visual representation of transaction flows through the payment lifecycle.Why it matters
Understanding the flow of payments through various stages—from initiation to settlement or failure—can be complex when looking at raw numbers alone. The Sankey graph offers an immediate, visual representation of transaction health. It allows you to easily spot drop-offs, analyze conversion flows, and understand volume distribution across your payment ecosystem at a glance.How it works
- Visual Flow: It visualizes the path of transactions based on the merchant’s data, showing how payments move through different states.
- Health Check: It serves as a visual health check, allowing you to quickly identify bottlenecks or unexpected patterns in your transaction lifecycle.
Who is it for?
This feature is designed for all dashboard users, especially those monitoring payment health, conversion analysts, and operations teams looking for quick visual insights into their payment pipeline.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.What’s new?
This release represents a coordinated effort across frontend and backend teams to modernize the 3DS experience:- Native Mobile 3DS Integration: A native 3DS SDK has been integrated into native iOS and Android SDKs, allowing merchants 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: Merchants 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.
Why it matters
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, merchants can now provide a premium, high-conversion experience:- Total UI Control: Merchants can maintain their app’s theme and look-and-feel throughout the entire payment process.
- Seamless Transitions: No more switching between native code and web views; the entire challenge happens in-app.
- Reduced Friction: Authenticating cards during vaulting simplifies the final checkout, as the 3DS requirement is handled upfront.
How it works
The process is now a unified client-server handshake:- Store: The mobile app stores card data securely in a Checkout Session.
- Authenticate: The app calls the new Checkout Sessions 3DS endpoint to retrieve the data needed for the native challenge.
- Challenge: The Native Mobile SDK uses the native 3DS integration to handle any challenge with the buyer’s bank.
- Finalize: The resulting 3DS data is stored back in the Checkout Session, which can then be used to create a successful, authenticated transaction server-side.
Custom 3DS authentication amounts
The ability for merchants to specify a 3D Secure (3DS) authentication amount that is different from the actual transaction authorization amount has been introduced.What’s new?
- Decoupled Authentication Amounts: Merchants can now trigger a 3DS challenge for a total amount that exceeds the amount being authorized in the immediate transaction.
- New API Syntax: A new field,
three_d_secure.amount, has been added to the/transactionsrequest, allowing merchants to set the desired authentication value. The API returns the same field to confirm the amount used for the 3DS handshake. - Validation Guards: 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.
Why it matters
This feature supports 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 authorized 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, merchants can authenticate the customer for the full cart total in one go. The resulting 3DS payload can then be applied to the first authorization and safely reused for subsequent, smaller authorizations without requiring the customer to complete another challenge.How it works
When a merchant creates a transaction, they can include thethree_d_secure.amount object:- Authentication: Gr4vy passes this custom amount to the 3DS provider/directory server.
- Authorization: The payment processor receives only the standard
amountdefined for that specific transaction. - Reuse: The 3DS data returned in the response (CAVV, ECI, etc.) remains valid for the higher authenticated amount, allowing the merchant to pass this data to other providers or ancillary services via vault forwarding.
Inbound webhooks visibility
A new feature provides merchants with complete visibility into asynchronous updates received from external systems by surfacing inbound webhooks as distinct events within the Dashboard.What’s new?
- Webhook Event Logs: Every incoming webhook received from a Payment Service Provider (PSP) or external system is now surfaced as a distinct transaction event on the transaction timeline.
- Payload Inspection: Merchants can inspect the raw headers and body of the inbound webhook directly from the Dashboard.
- Intelligent Transaction Linking: The system automatically identifies and links incoming callbacks to the correct transaction. To maintain a clean audit trail, events are only created when a definitive match to an existing transaction is found.
Why it matters
Previously, asynchronous interactions—such as a PSP notifying Gr4vy of a status change—were processed in the background without being explicitly logged in the transaction view. This “visibility gap” made it difficult for merchants to verify if a callback was actually received or to diagnose why a transaction state hadn’t updated as expected.By surfacing these inbound webhooks, merchants gain:- Self-Service Debugging: Teams can now verify webhook delivery and inspect payloads directly, without reaching out to support or checking internal logs.
- Full Audit Trail: Every transaction lifecycle is now fully transparent, covering both the requests Gr4vy sends out and the updates received back.
- Faster Issue Resolution: Technical teams can quickly identify malformed payloads or mismatched references that might prevent a transaction from updating correctly.
How it works
When an external provider sends a notification to a Gr4vy webhook listener:- Ingestion: Gr4vy processes the incoming request and attempts to resolve it to a specific Transaction ID.
- Event Creation: If a match is found, a new transaction event is added to the Transaction Detail view.
- Review: In the Events section of the Dashboard, you can click the event to view the full details of the webhook, including the exact data received from the provider.
Wero via Nuvei
Support for Wero, a new European digital wallet and instant payment solution, has been added via integration with Nuvei. This addition allows merchants to offer a unified, bank-backed payment method across key European markets.What is Wero?
Wero is a digital wallet and instant payment scheme developed by the European Payments Initiative (EPI), a consortium of major European banks and payment service providers.- The Unified Solution: Wero is designed to be the preferred, unified European alternative to non-European providers like Visa, Mastercard, and PayPal.
- Bank-Backed: It is heavily promoted by major banks across Europe as a secure, instant, and frictionless way to handle person-to-person (P2P), online shopping, and physical store payments.
- Instant Payments: Leveraging the SEPA Instant Credit Transfer scheme, Wero ensures that funds are transferred in real-time between bank accounts.
Why it matters
For merchants, Wero offers a unique competitive advantage by tapping into a payment method that European consumers are being actively encouraged to use by their own banks. It reduces reliance on international card schemes while providing a high-speed, secure checkout experience.European roll-out timeline
Wero is being rolled out in phases across the European Union:- Live Now (Late 2024 - Early 2025): Already operational in Belgium, Germany, and France.
- Upcoming (2026): Scheduled to go live in the Netherlands and Luxembourg.
- Future Outlook: Wero aims to become the “go-to” digital wallet for all instant payments across Europe, expanding its footprint as more banks join the initiative.