Apple Pay inside a Messages thread is the single most persuasive thing this channel does: a customer asks a question, gets an answer, and pays without leaving the conversation. It is also the piece with the most moving parts, and the one where "our platform supports Apple Pay" can mean several different amounts of work for you.
Apple splits the responsibility in a specific place, and knowing where it falls is what makes a provider's answer checkable.
Is Apple Pay optional for a provider?
No. Apple's required-features list for connecting brands to the channel opens with "Apple requires that you build and demonstrate support for the following features for approval to connect brands to Messages for Business", and the Apple Pay message appears there as Required on the bot and API path (Optional on the agent-triggered path).
So any approved provider has demonstrated it to Apple at least once. What varies is whether they have run it in production for a brand shaped like yours, and how much of the merchant plumbing they do for you. Ask for a reference, not a checkbox.
What does the provider host?
The gateway. Apple's Apple Pay tutorial has the provider host "the merchant payment token generator, also known as a payment gateway", and gives the concrete check: "Check your payment gateway is listening to POST requests on /paymentGateway."
Apple also fixes the freshness rule that a first implementation usually gets wrong: "Make sure you are obtaining a new merchant session every time you are sending a payment request." A merchant session is per request. A provider caching one is a bug waiting for a review to find it.
What do you have to bring?
The merchant identity, and it is more than an account. Apple states the prerequisite in one sentence: "Before you are able to send an Apple Pay in Messages for Business payload across the messaging system, you must have a valid merchant account, identifiers, certificates, and domain registrations."
Concretely that means four things on your side:
- A merchant account with the identifiers Apple Pay issues.
- A Payment Processing certificate, which Apple requires "associated with your Merchant account" for transactions to be accepted by the Apple Pay server, and which "expires every 25 months". Put the expiry in a calendar the day you create it.
- A Merchant Identity Certificate, which Apple has you download for the integration.
- A verified domain. Apple's instruction is to "Register this association within developer.apple.com. Otherwise, Apple Pay rejects your transactions."
None of that is the provider's to hold, which is why an Apple Pay launch involves whoever owns payments at your company rather than only whoever owns messaging. Apple puts a clock on it in its provider integration guidance: "The Apple Pay on Apple Messages for Business portion of the demo requires a merchant account and Apple Developer Program access. These may take several days to request and receive approval." The same approvals gate your side of the build, so start them before the rest of it is ready for them.
Why can't I trust the payment state in the reply?
Because Apple says not to, and the reason is sound: the reply describes what happened on the device, and your money moves in your payment system. Apple's instruction is direct: "Confirm that the test payment transaction went through your payment system, rather than relying on the state of the return message."
Design the flow accordingly. The message that tells a customer their order is confirmed should be triggered by your payment system's own record, not by the inbound message that says the sheet was completed. This is the most common way an otherwise finished Apple Pay integration produces a wrong customer outcome.
What does this add to a launch plan?
Three things worth sequencing before the review, because they are all slower than they look:
- The merchant credentials. Certificates and domain registration are Apple Developer account work with their own approvals.
- The gateway integration. Your payment processor's token handling has to meet the provider's gateway, and both sides need a test transaction.
- The demonstration. Apple's Experience Review looks at the interactions you have actually built, so an Apple Pay flow that exists in the platform but not in your conversation gets you no credit for it. What Apple's brand review involves covers what the recording has to show.
If Apple Pay is the reason the channel is on your roadmap, make it a first-round question with providers rather than a phase two: it is the part of the evaluation where "supported" hides the most variation. What a Messaging Service Provider is, and how to choose one covers the rest of that conversation.
Every Apple requirement on this page comes from Apple's own documentation, read on 4 September 2026: Apple Pay, Messages for Business REST API required features and MSP integration.