Subscriptions with Apple Pay

MoneyHash handles the entire Apple Pay recurring billing setup for you - tokenization, the initial charge, and every renewal after it. You configure a connection, a payment flow, and a plan group once; MoneyHash manages the Apple Pay network-token lifecycle from there. You don't build or maintain the multi-step Apple Pay recurring flow yourself.

Once the setup on this page is in place, Apple Pay appears automatically as a payment option on your subscription embed or hosted page - no extra frontend work beyond what your existing subscription checkout already does.

Looking for the SDK integration steps?

This page covers the dashboard configuration behind Apple Pay subscriptions - connections, flow rules, plan groups. If you're implementing a custom recurring Apple Pay flow at the SDK level (Merchant Tokens / MPAN), see Apple Pay Integration Steps instead.

Most subscription merchants don't need that page - this setup requires no SDK-level recurring code.

How it works

The customer taps Apple Pay on your subscription embed or hosted page.
Apple Pay shows a payment sheet pre-populated with the subscription's billing details - amount, frequency, and trial information.
On authorization, MoneyHash tokenizes the Apple Pay network token, runs the initial charge as a customer-initiated transaction (CIT), and stores the token.
Every later invoice is charged automatically as a merchant-initiated transaction (MIT) using that stored token - no further action from the customer.

What you need first

Three things have to be in place before Apple Pay can appear on a subscription checkout.

1. An Apple Pay self-serve connection

Your account needs an Apple Pay self-serve connection in Connections, with your PSP's card method added as the underlying method. Your PSP must support network-token processing with cards.

A provider-hosted Apple Pay integration will not work here

Recurring billing requires MoneyHash to manage the network-token lifecycle directly - tokenization, vault storage, and cryptogram generation for every later charge. Only the self-serve connection type gives MoneyHash that control.

2. A payment flow with two routing rules

Subscriptions with Apple Pay need a Payment Flow - Payment Defaults alone is not enough. The flow must contain both of these rules:

Rule	Purpose	Configuration
Apple Pay (CIT)	Makes the Apple Pay button appear and handles the first payment	Flow rule `APPLE_PAY`, transaction type customer-initiated, provider = your self-serve Apple Pay connection
Card MIT with Network Token	Charges every later invoice automatically	Payment method trigger `CARD`, transaction type merchant-initiated, token type Network Token - MoneyHash Stored, provider = the underlying PSP supporting network tokens

Without the first rule, Apple Pay is never offered at checkout. Without the second, the subscription can't take recurring payments at all.

Both rules must use the same currency

If the Apple Pay rule is set for USD and the card MIT rule for AED, the flow fails validation when you try to use it with a subscription.

3. A plan group with the flow assigned

Create your Plan with its amount, currency, billing interval, and optional trial period. Add it to a Plan Group, then assign the flow from step 2 to that plan group. This is what connects your Apple Pay-capable flow to the subscription checkout.

Auto-charge on or off

Auto-charge enabled (charge_automatically: true) - the customer authorizes once with Apple Pay, and MoneyHash charges every subsequent invoice automatically on its due date. The embed shows only Card and Apple Pay.

Auto-charge disabled - all available payment methods are shown, including Apple Pay, and the customer pays each invoice manually when a new billing cycle begins.

Trials change the first charge

	No trial	With trial
First charge amount	First invoice amount	1 currency unit (e.g. 1 USD)
Operation	`purchase`	`authorize`, voided immediately after
Result	First invoice PAID, subscription ACTIVE	Subscription TRIAL; the first real charge fires as an MIT when the trial ends

Why the 1-unit charge on trials

That authorization exists only to validate the card and capture the token. It's voided right away and never captured - the customer isn't charged for it.

If the first payment fails

The token is discarded and the subscription stays INCOMPLETE. The customer has to retry, which means a fresh Apple Pay authorization - the previous one can't be reused. The customer-facing result reflects the initial charge outcome, not the tokenization step.

Common errors and troubleshooting

Apple Pay isn't showing on my subscription checkout. +

Check three things, in order: the Apple Pay connection is self-serve rather than provider-hosted, the flow contains the Apple Pay CIT rule, and the flow is assigned to the plan group.

Recurring charges aren't going through, but the first payment worked. +

The Card MIT rule with Network Token is likely missing or misconfigured. The first payment only needs the Apple Pay CIT rule - every later one needs the MIT rule.

A customer on a trial saw a 1 USD charge. Why? +

That's the authorization used to validate the card and store the token. It's voided immediately and never captured - no action needed.

My flow won't save or validate against the subscription. +

The most common cause is a currency mismatch between the Apple Pay rule and the card MIT rule. Both must use the same currency.

Can I use Payment Defaults instead of a flow? +

No. Apple Pay with subscriptions requires a payment flow containing both routing rules - Payment Defaults alone doesn't support this.

Subscriptions - plans, plan groups, and subscription lifecycle
Recurring & Unscheduled Payments - how MIT charges work outside subscriptions
Tokenization - how MoneyHash stores and reuses payment tokens
Native Pay Integration Types - SDK-level Apple Pay integration steps