The Changelog

​

Windcave (card)

​

What’s new?

• Card payments via Windcave: Accept credit and debit card payments through Windcave, using Gr4vy client-side integrations to collect and tokenize card details.
• Full transaction lifecycle: Authorize, capture (including delayed and partial capture), void, and refund (including partial refunds) through the standard transaction flow.
• 3-D Secure pass-through: Forward externally authenticated 3DS data so authentication performed by your own MPI is passed through to Windcave on the transaction.
• Stored cards: Tokenize cards for card-on-file payments, with cardholder- and merchant-initiated indicators for recurring debits.
• Transaction synchronization: Keep payment states synchronized with Windcave using webhooks to guard against interrupted checkouts.

​

Integration

​

Adyen Pay by Bank (US)

​

Direct capture optimization

​

What’s new?

• Single-step sale on supported connectors: On connectors that support direct capture, intent: capture transactions are sent to the payment service as a single combined authorization and capture, rather than two separate steps.
• Faster immediate-capture flow: Removing the second round-trip to the payment service can lower latency on immediate-capture transactions, with no integration changes required.
• Unchanged where unsupported: Connectors that don’t yet support direct capture continue to authorize and then capture as before.

​

Good to know

• the anti-fraud decision for the transaction is review.
• gift cards are used as part of the transaction (multi-tender).
• the payment method uses an alternative, non-card scheme.

​

How it works

​

ACH via Nuvei

​

What’s new?

• US ACH support: Submit bank account details directly through the Gr4vy API to process ACH payments with Nuvei.
• Direct capture and refunds: Process ACH transactions with direct capture, then issue full or partial refunds through the standard transaction flow.
• Transaction synchronization: Keep ACH payment states synchronized with Nuvei as asynchronous updates are processed.
• Idempotency support: Gr4vy generates and sends a clientRequestId with every request to Nuvei. To enable idempotency, contact your Nuvei Account Manager to make clientRequestId mandatory on your account.

​

Integration

​

Konbini via Adyen

​

What’s new?

• Cash payments in Japan: Buyers receive a payment voucher during checkout and pay in cash at a participating convenience store, including Lawson, FamilyMart, Mini Stop, and Seicomart.
• Redirect integration: Present the buyer with the Adyen-hosted approval URL to generate the voucher. Because the buyer pays in cash later, the final transaction status arrives via webhook rather than a redirect back to Gr4vy.
• Direct integration: Web, iOS, and Android direct integrations are available using the Adyen SDKs.
• Refunds: Captured transactions can be refunded in full or in part.

​

Integration

​

ACH Direct Debit via Adyen

​

What’s new?

• Bank debit in the US: Buyers enter their bank account and routing numbers on the Adyen Drop-in to authorize the debit.
• Recurring payments: Store the bank account for recurring ACH debits.
• Redirect integration: Open the Adyen-hosted approval URL in a popup so the buyer can complete the Drop-in. Rely on webhooks to detect the final transaction status.
• Direct integration: Web, iOS, and Android direct integrations are available using the Adyen SDKs.
• Refunds: Captured transactions can be refunded in full or in part.

​

Integration

​

Flow: Split routing

​

What’s new?

• Split routing outcome: A new outcome type in Flow that routes matched transactions across up to four connector variants, each assigned a defined percentage of traffic. A variant is randomly selected for each transaction using those weights, and all percentages must total exactly 100%.
• Split routing condition: A new condition that can be added to any routing rule to define a probability threshold. For example, sending 30% of matching transactions into a specific branch. Only one split routing condition is allowed per rule.
• Variant performance comparison: Once a split routing rule is active, variant performance can be compared directly in Insights, filtered to the exact traffic split. This makes it straightforward to evaluate authorization rates, costs, and outcomes across connector configurations side by side.

​

Why it matters

​

Getting started

​

Card data enrichment from connector response

​

What’s new?

• Connector-response fallback: When the scheme-published BIN tables don’t yet identify the card scheme, card type (credit or debit), or country of issue for a transaction, these fields are now populated directly from the values returned by the downstream connector. This is currently supported for Stripe and Fiserv.
• Retroactive backfill via transaction sync: The enrichment is applied through the connector sync endpoints. Merchants with existing transactions that have incomplete card metadata can retroactively populate these fields by triggering a sync, with no need to reprocess payments.

​

Why it matters

​

Paysquad connector

​

What’s new?

• Group payments: Let buyers invite friends, family, or colleagues to each pay their share of a single order. Paysquad settles the full amount to the merchant once all contributions are collected.
• Redirect integration: Buyers are sent to a Paysquad-hosted page to complete the group payment. Webhooks deliver the final transaction status once the squad funds the order.
• Full refunds: Captured transactions can be refunded in full through the standard Gr4vy API.
• Custom approval window: Set how long a buyer has to complete the group payment before the order expires and inventory is released.
• Deep linking: The Paysquad approval URL can be opened directly in a native mobile app.

​

Integration

​

Forter v10.2 upgrade

​

What’s new?

• Opt-in Forter v10.2 API: When the dashboard toggle is enabled on a connector, checkout and decision requests are sent against Forter’s v10.2 endpoints, with all field names mapped to the new schema. Without the toggle, requests continue to use v2.1.
• Dashboard toggle: Opt in to v10.2 from a per-connector setting in the dashboard. v2.1 remains the default for existing integrations until the toggle is enabled.
• APMs and digital wallets: Anti-fraud decisions now cover PayPal, Pay in 4 and other buy now, pay later (BNPL) methods, gift cards, and wallet-based payments, in addition to cards and 3DS.
• Standardized Apple Pay and Google Pay payloads: Wallet payloads are sent in Forter’s v10.2 standard format, replacing the non-standard shape previously used on v2.1.
• Foundation for advanced Forter products: The v10.2 integration is the prerequisite for Forter’s Account Protection, Abuse and Policy Builder, and AI Agent capabilities, which are not available on v2.1.

​

How it works

​

Secure Fields UX enhancements

​

What’s new?

• Auto focus: Set autoFocus on a field to focus it as soon as it loads, so buyers can start typing without an extra click.
• Auto advance: Configure auto advance on the parent SecureFields instance to move focus to the next field as soon as the current field validates, with an optional field order to control the sequence.
• Input masking: Configure maskInput to hide the card number and security code — mask on blur, mask in real time as the user types with maskOnInput, or keep the last four digits visible with showLastFour. A custom masking character is supported.
• Programmatic mask toggle: Call redactValue() / unredactValue() on a field to build a custom show/hide control, and respond to state changes via the onRedacted / onUnredacted React callbacks or the redacted / unredacted events on the JS SDK.
• Field reset: Each field instance exposes a clear() method to reset its value programmatically — useful for “use a different card” flows.
• Scheme icons: Enable showSchemeIcons on the card number field to render the detected card scheme inline, with options for additional co-branded schemes and placeholder icons before a scheme is detected.

​

GCash via Adyen

​

What’s new?

• Redirect integration: Create a transaction and redirect the buyer to the Adyen-hosted GCash approval page. After authorization, the buyer returns to your redirect_url.
• Direct integration: Use the Adyen SDK on iOS, Android, or web for a native checkout experience without an external browser redirect.
• Recurring payments: Set store: true on the initial transaction to save the buyer’s GCash wallet. Subsequent merchant-initiated charges are sent directly to Adyen using the stored payment method — no second redirect required.

​

How it works

​

PayPal direct integration

​

What’s new?

• Direct integration on PayPal: Create a transaction with integration_client set to web, ios, or android to use the PayPal JS SDK or mobile SDKs directly on your checkout surface.
• Session data for SDK initialization: The transaction response includes a session_token. Exchange it at POST /transactions/{id}/session to receive the session_data (order ID, client ID, merchant ID, currency, intent, funding source) and a tokenized default_completion_url to use after buyer approval.
• Server-created orders: Gr4vy creates the PayPal order before the SDK is rendered, so cart items, billing details, and shipping details continue to flow through to PayPal, and every attempt is observable in the Gr4vy dashboard.

​

How it works

​

Recurring Pix payments via Adyen

​

What’s new?

• Mandate creation: Create a recurring Pix billing plan with a configurable frequency (weekly, monthly, quarterly, half-yearly, or yearly), a fixed or variable amount, start and end dates, and a buyer-facing statement description.
• Flexible first-charge behavior: Create the mandate without taking a payment, or authorize the mandate and charge the first amount in a single call.
• Scheduled recurring charges: Pull subsequent payments against the stored mandate on the schedule defined in the plan, with optional business-day adjustment.
• Mandate cancellation: Revoke an active mandate by deleting the saved payment method through DELETE /payment-methods/{id}.
• Webhook handling: Full lifecycle visibility for mandate activation, mandate revocation, and individual charge outcomes.

​

How it works

​

Worldline Connect connector

​

What’s new?

• Card payments: Accept credit and debit card payments through Worldline Connect across a broad range of countries and currencies.
• Advanced card features: Support for delayed capture, partial capture, partial refunds, void, and zero authorization for card verification.
• Digital wallet and network token support: Accept Apple Pay and Google Pay, with network tokenization enabled by default.
• 3-D Secure: Support for 3DS authentication.
• Click to Pay: Accept Click to Pay transactions via standard card instrument routing.
• Airline data: Pass detailed airline and passenger data for travel merchants.
• Transaction sync: Automatic synchronization of transaction status via Worldline webhooks.

​

Integration

​

Shift4 connector

​

What’s new?

• Card payments: Accept credit and debit card payments through Shift4 across a broad range of countries and currencies. Support for delayed capture, partial capture, partial refunds, void, and zero authorization for card verification.
• Incremental authorization: Increase an authorized amount after initial approval — ideal for hospitality and car rental flows where the final charge may exceed the initial estimate.
• Digital wallet and network token support: Accept Apple Pay and Google Pay, as well as network tokenization for improved security and authorization rates.
• 3-D Secure: Support for universal 3DS authentication.
• Payment method tokenization: Store card details for recurring payments and one-click checkout.

​

Integration

​

Update stored payment method details

​

What’s new?

• New PUT /payment-methods/{payment_method_id} endpoint for updating a stored payment method.
• Fields you can update:
  • expiration_date: The new expiration date for the card (for example, 12/30).
  • scheme_transaction_id: A scheme transaction identifier to associate with the payment method.
  • scheme_transaction_id_scheme: The card scheme associated with the scheme_transaction_id (for example, visa, mastercard).

​

Behavior notes

• Setting scheme_transaction_id to null also clears scheme_transaction_id_scheme.
• If scheme_transaction_id is set and scheme_transaction_id_scheme is both omitted from the payload and previously unset, it defaults to the payment method’s scheme.

​

Why it matters

​

How it works

var paymentMethod = await client.PaymentMethods.UpdateAsync(
  paymentMethodId: "ef9496d8-53a5-4aad-8ca2-00eb68334389",
  paymentMethodUpdate: new PaymentMethodUpdate() {
    ExpirationDate = "12/30",
    SchemeTransactionId = "123456789012345",
    SchemeTransactionIdScheme = CardScheme.Visa,
  }
);

​

Network token forwarding in Vault Forward

​

What’s new?

• New template placeholders for injecting network token data into your Vault Forward request body:
  • {{ CARD_NETWORK_TOKEN_X }}: The network token for the card. Auto-provisioned if not yet available.
  • {{ CARD_NETWORK_TOKEN_EXPIRATION_DATE_X }}: The network token’s expiration date (and variants for month/year parts).
  • {{ CARD_CRYPTOGRAM_X }}: A one-time cryptogram generated for the network token.
• Fallback placeholders (_OR_EMPTY_STRING variants) for graceful degradation when network token provisioning fails — each network-token placeholder has a corresponding _OR_EMPTY_STRING variant that returns "" instead of erroring. Examples:
  • {{ CARD_NETWORK_TOKEN_OR_EMPTY_STRING_X }}
  • {{ CARD_CRYPTOGRAM_OR_EMPTY_STRING_X }}

​

Why it matters

​

How it works

{
  "card": {
    "number": "{{ CARD_NETWORK_TOKEN_1 }}",
    "expiry": "{{ CARD_NETWORK_TOKEN_EXPIRATION_DATE_MM_1 }}/{{ CARD_NETWORK_TOKEN_EXPIRATION_DATE_YY_1 }}",
    "cryptogram": "{{ CARD_CRYPTOGRAM_1 }}"
  }
}

​

Gift card usage data

​

What’s new?

• Usage fields on gift cards: Each stored gift card now includes last_used_at, usage_count, cit_last_used_at, and cit_usage_count.
• Sorting support: The list buyer gift cards API supports a sort_by query parameter to order results by any of these fields, with the most recently or frequently used card returned first.

​

Integration

​

Recurring GCash payments via dLocal

​

What’s new?

• Recurring enrollment flow: Enroll buyers for recurring payments during an initial redirect transaction.
• Token storage support: Save the approved GCash payment method for future charges by setting store: true.
• Recurring source flag: Set payment_source: recurring to initiate and process recurring billing flows.
• Wallet enrollment details: Pass connection_options.dlocal-gcash.wallet fields to satisfy dLocal recurring enrollment requirements.

​

Integration

​

Airwallex connector

​

What’s new?

• Card payments: Accept credit and debit card payments through Airwallex.
• Advanced card features: Support delayed capture, partial capture, partial refunds, void, and zero authorization for card verification.
• Digital wallet and network token support: Accept Apple Pay and Google Pay with wallet pass-through and network tokenization.
• 3-D Secure and risk data support: Use hosted or pass-through 3DS and send billing and device fingerprint data to improve risk decisions.
• Global coverage: Process transactions across a broad set of supported countries and currencies.

​

Integration

​

Custom expiration date for push payments

​

What’s new?

• New approval_expires_at field: A new top-level field on TransactionCreate sets the expiration date and time for the payment reference, in ISO 8601 format.
• Connector support: OXXO and Monato SPEI now read and propagate this value when the payment reference is created.
• Precedence rules: Connector-level overrides set via connection_options still take highest priority. If approval_expires_at is not set, each connector’s default expiration window applies.

​

Why it matters

​

How it works

var transaction = await client.Transactions.CreateAsync(
  transactionCreate: new TransactionCreate()
  {
    Amount = 1299,
    Currency = "MXN",
    ApprovalExpiresAt = DateTimeOffset.Parse("2026-04-10T23:59:59Z"),
    PaymentMethod =
      TransactionCreatePaymentMethod.CreateCheckoutSessionWithUrlPaymentMethodCreate(
        new RedirectPaymentMethodCreate()
        {
          Method = "oxxo",
          RedirectUrl = "https://example.com/callback",
        }
      ),
  }
);

​

Unlimit connector

​

What’s new?

• Card payments: Accept credit and debit card payments from buyers around the world through Unlimit’s platform.
• Advanced features: Support for delayed capture, partial capture, partial refunds, void, and zero authorization for payment verification.
• Digital wallet integration: Accept Apple Pay, Google Pay, and other digital wallet payments alongside traditional card payments.
• Network tokenization: Use network-level tokenization for enhanced security and higher approval rates on recurring payments.
• 3-D Secure: Support for 3DS pass-through authentication to meet Strong Customer Authentication (SCA) requirements.
• Payment method tokenization: Store card details for future recurring payments and one-click checkout experiences.
• Global reach: Supports transactions across a broad set of countries and currencies worldwide.

​

Integration

​

Direct bank payments with ACH, SEPA, and BACS

​

What’s new?

• Direct bank payment method: Submit bank account details directly using method: "bank" with scheme set to ach, sepa, or bacs on the transaction API. No Plaid Link session required.
• Multi-scheme support: Process ACH payments with account and routing numbers, SEPA payments with IBAN, or BACS payments with account number and sort code.
• Vault and reuse: Store bank account details for recurring payments by setting store: true, or vault them independently via the POST /payment-methods endpoint.
• Plaid raw data extraction: When using Plaid with a connector that doesn’t support Plaid tokens, the system now automatically extracts raw bank details (ACH, SEPA, or BACS) from Plaid and passes them to the connector.
• Force direct bank details: A new setting on bank payment connectors (such as Adyen bank) skips the Plaid token exchange and fetches raw bank details directly, saving an API call per payment.

​

Why it matters

​

How it works

​

Swish and Vipps via Adyen

​

What’s new?

• Swish support: Accept payments in Sweden via Swish, an instant mobile wallet and payment app used by millions of Swedish consumers.
• Vipps support: Accept payments in Norway via Vipps, a mobile wallet and payment app that is prevalent in the Norwegian market.
• Redirect integration: Both payment methods use a seamless redirect flow where buyers approve payments directly in their mobile wallet apps.
• Direct integrations: Adyen Web, iOS, and Android SDKs are available for native direct-integration patterns on supported platforms.

​

Native 3DS for Secure Fields

​

What’s new?

• In-page challenge handling: Secure Fields includes built-in logic to intercept 3DS challenge requirements and trigger a modal or inline challenge directly on the page instead of redirecting the user.
• 3DS2 support: The integration is fully optimized for 3DS2, supporting frictionless flows, browser-based fingerprinting, and step-up challenges.
• Consistent backend: This feature uses the same Checkout Sessions infrastructure as the native mobile 3DS SDKs, ensuring consistent 3DS data management across web and mobile platforms.
• Custom styling: Customize the appearance of the 3DS challenge container to match your site’s design.

​

How it works

​

New anti-fraud connector: Riskified

​

What’s new?

• Real-time decision mapping: Riskified’s approve decision maps to accept in Gr4vy; decline results in an immediate reject.
• Transaction lifecycle sync: Gr4vy keeps Riskified synchronized with the full transaction lifecycle, including refunds and voids. Enable the “Limited Actions” flag to restrict updates to initial transaction processing only.
• Device fingerprinting: Pass a session_id as an anti_fraud_fingerprint via the API to improve decision accuracy when using Riskified’s Beacon technology.
• Enhanced data pass-through: Supports detailed cart_items (mapped to Riskified line_items) and custom merchant-defined data.

​

Recurring Pix payments via dLocal

​

What’s new?

• Pix Automático support: Full integration with the official recurring Pix flow required for automated bank transfers in Brazil.
• Standard recurring flags: Use Gr4vy’s existing recurring payment flags to initiate and manage Pix Automático mandates.
• Asynchronous mandate setup: The system handles initial mandate creation and provides the redirect or QR code for the customer to authorize the recurring setup in their banking app.
• Status synchronization: Webhook handlers have been updated to process Pix Automático mandate and recurring capture status updates from dLocal.

​

How it works

​

Pix via Adyen

​

What’s new?

• Native Pix integration: Process Pix transactions through the standard Adyen connector by selecting the Pix payment method type.
• QR code and copy-and-paste support: The integration generates Pix QR codes and dynamic “Copy and Paste” keys delivered to the buyer during checkout.
• Automated status updates: Adyen webhook handlers have been updated to manage the asynchronous nature of Pix, automatically transitioning transactions from pending to captured once the customer completes the transfer.
• Refund support: Standard refund operations are supported for full transaction lifecycle management.

​

How it works

​

Bre-B and Capitec via dLocal

​

What’s new?

• Bre-B: A popular local payment method now available through the dLocal integration.
• Capitec: South Africa’s widely used Capitec payment method is now supported for one-off transactions.

​

How it works

​

Klarna via Nuvei

​

What’s new?

• Klarna payment options: Support for Pay in 30 days, Pay in 3 installments, and Financing through the Nuvei gateway.
• European coverage: Available across supported European markets where both Klarna and Nuvei operate.
• Dashboard configuration: Configure Klarna via Nuvei directly in the connector settings within the Gr4vy dashboard.

​

Date-time range picker

​

What’s new?

• Custom date range controller: A new date range controller at the top of the dashboard pages lets you define any custom start and end date and time to filter your view.
• Simplified transaction filtering: Date columns in the Transactions table and Reports now function primarily for sorting. The new top-level controller handles all date filtering.
• Precise Insights windows: You are no longer limited to “Last 24 hours” or “Last 7 days.” Select the exact time window relevant to your investigation.

​

Why it matters

​

Who is it for?

​

Online Banking Czech Republic via Adyen

​

Idempotency for refunds, voids, and captures

​

What’s new

• Idempotency header support: The /refunds, /voids, and /captures endpoints accept Idempotency-Key for POST requests.
• Safe retries and duplicate protection: When you retry with the same key and payload, Gr4vy returns the cached response instead of reprocessing the financial operation.
• Consistent error handling: Reusing a key with a different payload returns a validation error, matching core transaction behavior.

​

How it works

​

Pay by bank orchestration with Plaid

​

Issuer installments support for Embed & payment links

​

3DS sandbox simulator

​

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

​

How it works

1. Register Rules: Use the /three-ds-scenarios endpoint to register a rule. For example, you could create a rule where any transaction with the email challenge@example.com triggers a 3DS challenge.
2. Process Transaction: When a transaction is processed in sandbox, Gr4vy checks for any matching mock rules.
3. 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

• 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)

​

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

​

How it works

​

Webhook retry improvements

​

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

• 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

​

Transaction search by buyer external ID

​

What’s new?

• Expanded Search Index: The transaction search index now includes the buyer.external_identifier field.
• 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

​

How it works

​

Payment lifecycle graph

​

What’s new?

​

Why it matters

​

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?

​

Native 3DS for mobile

​

What’s new?

• 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

• 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

1. Store: The mobile app stores card data securely in a Checkout Session.
2. Authenticate: The app calls the new Checkout Sessions 3DS endpoint to retrieve the data needed for the native challenge.
3. Challenge: The Native Mobile SDK uses the native 3DS integration to handle any challenge with the buyer’s bank.
4. 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

​

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 /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.
• 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

​

How it works

1. Authentication: Gr4vy passes this custom amount to the 3DS provider/directory server.
2. Authorization: The payment processor receives only the standard amount defined for that specific transaction.
3. 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

​

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

• 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

1. Ingestion: Gr4vy processes the incoming request and attempts to resolve it to a specific Transaction ID.
2. Event Creation: If a match is found, a new transaction event is added to the Transaction Detail view.
3. 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

​

What is Wero?

• 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

​

European roll-out timeline

• 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.

​

How it works

​

Important note for sandbox testing