Skip to main content
Use this guide to implement a production wallet flow where the frontend handles wallet UX and your backend performs Core API calls. The core contract is simple: capture encrypted payload.card_data in onCapture and forward it unchanged to your server.

Flow Overview

  1. Initialize SDK in the frontend
  2. Create a transaction
  3. Mount wallet buttons
  4. On capture, send encrypted data to backend
  5. Backend creates transaction in Rinne API
Forward payload.card_data as encrypted secure data to your backend. Avoid logging sensitive payload fields in plaintext logs.

Frontend Implementation

checkout.ts

Google Pay Authentication Methods

By default Google Pay only returns device-tokenized cards (network_token + cryptogram), which carry a liability shift and need no further authentication. Passing allowedAuthMethods: ['UNAUTHENTICATED', 'THREE_DS'] also accepts cards saved to the shopper’s Google account, which arrive as an encrypted PAN with no liability shift. An UNAUTHENTICATED capture behaves like a keyed card: it has no cryptogram, and you can — and generally should — run 3DS on it using the same session-first or transaction-first flow as the Card element. Branch on the discriminant before deciding:
See allowedAuthMethods for the full contract.

Backend Example (Node.js)

server.ts
Never call Rinne transaction APIs directly from the browser. Keep your API key server-side.

Verification Checklist

Wallet checkout is correctly implemented when:
  • onCapture sends encrypted payloads to your backend
  • Backend creates transaction with your API key
  • fail() is called whenever backend processing fails
  • If transaction status is AWAITING_3DS, your checkout continues with the 3DS flow