Skip to main content
Wallet transactions use the same transaction endpoint as card payments, but card_data is tokenized and captured by wallet elements.
Wallet and 3DS are complementary. If a wallet transaction returns AWAITING_3DS, continue with either official 3DS flow (session-first or transaction-first), based on your organization architecture.

Architecture

  1. Frontend creates a wallet transaction object with rinne-js.
  2. Frontend mounts Apple Pay and Google Pay elements.
  3. onCapture returns encrypted payload.card_data and payload.payment_method.
  4. Frontend sends payload data to your backend.
  5. Backend calls transaction create endpoint in self or merchant context.
Do not call the Core API directly from the browser. Keep x-api-key on your backend only.
Treat payload.card_data as a secure encrypted payload. Forward it to your backend without decrypting, reformatting, or storing sensitive values in logs.
network_token and cryptogram are accepted only as encrypted values (ev: prefix), exactly as the wallet elements emit them. Plaintext values are rejected with 400 VALIDATION_ERROR.

Transaction endpoint context

Map rinne-js payload to API fields

Backend transaction request example

Backend handler example (Node.js)

server.ts

Frontend capture handling

In onCapture, always call fail() when backend processing fails so wallet UI can recover.

3DS behavior in wallet flows

Most wallet payloads already contain tokenized authentication data (network_token + cryptogram). If the transaction still returns AWAITING_3DS, run your regular 3DS flow:
  1. Create a 3DS session.
  2. Complete challenge in frontend with tds_session_id.
  3. Call authenticate endpoint in your context:
    • Self: /v1/transactions/{transactionId}/authenticate
    • Merchant: /v1/merchants/{merchantId}/transactions/{transactionId}/authenticate
You can also run session-first 3DS before transaction creation if that better matches your checkout orchestration.

Optional policy flags for wallet card transactions

The same card transaction flags are available in wallet-backed card requests:
  • require_3ds: true: use this when you want wallet transactions to deterministically enter AWAITING_3DS in your transaction-first flow.
  • refuse_on_challenge: true: use this when you want challenge-triggered wallet transactions to fail fast as REFUSED (status_reason = CHALLENGE_NOT_ALLOWED) instead of requiring challenge handling.
require_3ds and refuse_on_challenge cannot both be true in the same transaction request.

Production checklist

Wallet checkout is ready for production when:
  • You send wallet card_data only to your backend.
  • You create transactions with idempotent request_id values.
  • You call fail() in onCapture for all backend failures.
  • You handle PROCESSING, APPROVED, REFUSED, and AWAITING_3DS outcomes.
  • You use webhooks for final transaction state updates.