Choose a wallet data path
Tokenized, encrypted and decrypted wallet inputs use different fields.
Collect with customer interaction
Wallet capture happens while the customer interacts with your checkout. Send the chosen representation to your server; do not mix alternatives. Prefer tokenized collection unless your approved integration explicitly handles wallet data directly.
Select the representation
Representation payment_details fields Additional data Collect.js token payment_token Token carries wallet data Encrypted Apple Pay applepay_payment_data Encrypted wallet payload Encrypted Google Pay googlepay_payment_data Encrypted wallet payload Decrypted Apple Pay card_number, card_exp, decrypted_applepay_data=true cardholder_auth.cavv Decrypted Google Pay card_number, card_exp, decrypted_googlepay_data=true cardholder_auth.cavv Customer request contract Subscription request contract
Registration can transact immediately
Wallet registration consumes short-lived cryptographic data through an immediate transaction. Google Pay defaults to a zero-value authorization; Apple Pay follows the payment-sheet amount. Any upfront type/amount must match what the customer approved. Save the customer/subscription identity and initial transaction identity separately.
Resolve subscription source conflicts
The wallet guides show top-level plan_amount/month_frequency/day_of_month and YYYY-MM-DD start_date. The current subscription reference and recipe use plan_details, with differing examples inside it. Follow the current contract for the selected schedule variant; do not combine both layouts. Confirm the intended first billing date and never reuse old source-example dates.