Save wallet payments for later
Understand the immediate transaction, consent and transaction linkage involved in saving a digital wallet.
Prepare the wallet
Configure the wallet before collecting payment data. Apple Pay requires registered domains and verification files. Obtain agreement for the intended future charges; the wallet interaction and your application must describe that agreement.
Store and retain the original transaction
POST /v5/customers accepts a payment_details.payment_token. Set cit_mit.stored_credential_indicator to stored and initiated_by to customer. Wallet registration performs an immediate transaction: Google Pay defaults to a zero authorization; Apple Pay follows the amount in its wallet data. An upfront sale or authorization requires matching type and amount, including the amount shown by Apple Pay. Persist both the resulting customer ID and transaction ID. Saving wallet data is not merely a database write.
Charge the saved method
For a later sale, supply payment_details.customer_vault_id and cit_mit.initial_transaction_id. Use stored_credential_indicator: used, with initiated_by reflecting who initiated this charge. Do not reuse the original wallet cryptogram. Create customer contract Create sale contract
Schedule a subscription
Wallet subscriptions also consume perishable wallet data during registration. The source subscription tutorial uses flattened plan fields; the current endpoint contract uses plan_details or plan_id. Follow the contract when constructing a request. Preserve a documented schedule and initial charge amount, then handle subsequent payment outcomes separately. Subscription contract and variants