Wallet registration through later billing
Compare a merchant-managed vault schedule with gateway-managed recurring billing.
Show the agreement first
Collect.js can display Apple Pay recurring terms before producing payment_token. Configure recurring amount, interval, start date and management URL. The source examples contain historical dates and even disagree between July/October dates and displayed day; choose one current agreement and apply it consistently.
Merchant-managed billing
Register the token with POST /api/v5/customers. Preserve customer id and transaction_id from the registration response. A later sale uses customer_vault_id plus cit_mit.stored_credential_indicator=used, initiated_by=merchant and initial_transaction_id. Registration and later-sale IDs identify different operations. { "amount": 10, "payment_details": { "customer_vault_id": "<SAVED_CUSTOMER_ID>" }, "cit_mit": { "stored_credential_indicator": "used", "initiated_by": "merchant", "initial_transaction_id": "<REGISTRATION_TRANSACTION_ID>" } }
Gateway-managed billing
A subscription registration consumes the token and establishes a schedule. The gateway triggers later recurring sales; your application must not independently charge the same schedule. Preserve subscription and initial-transaction identifiers and monitor payment failures or pauses. Modify/cancel the subscription explicitly. Schedule and data variants Recurring event samples