How to Accept Apple Pay on Your Website in Bahrain

Apple Pay lets a customer pay on your website with Face ID, Touch ID or a double-click, without typing a card number. Adding it is not difficult, but it has a few moving parts that catch people out: a payment provider that supports it, a verified domain, and a server that confirms every payment itself. This guide walks through each one for a Bahrain business.

What You Need Before You Start

You do not connect to Apple directly to take money. Apple Pay is a way of presenting a card the customer already has; the payment itself still runs through a payment provider and an acquiring bank. So the shopping list is short:

• A payment provider (PSP) that supports Apple Pay in Bahrain. Tap Payments is one example. Ask your provider directly whether Apple Pay is enabled for Bahrain merchants on your account, not just listed on their website.
• An approved merchant account. Your provider will onboard your business with its usual documents before any live payment method is switched on. Apple Pay is usually an extra method enabled on top of card acceptance.
• HTTPS on every checkout page. Apple Pay on the web only runs on secure pages. If your site still has mixed content or an expired certificate, fix that first.
• A domain you control. You will need to place a verification file on the exact domain where the button appears, so you need access to the web server or hosting panel.

Some providers also let you use your own Apple Developer account and merchant identifier. Most small businesses do not need that. When the provider handles the Apple side, you avoid managing Apple certificates yourself, and that is usually the simpler route.

Step 1: Verify Your Domain

Apple will only show the Apple Pay button on domains that have been registered for the merchant. Registration works like this:

1. Your provider gives you a file called apple-developer-merchantid-domain-association, usually from its dashboard or support team.
2. You publish it, unchanged, at https://yourdomain.bh/.well-known/apple-developer-merchantid-domain-association.
3. You (or the provider) register the domain, and Apple fetches the file to confirm you control it.

Three details matter here. The file must be served over HTTPS with no redirect. It must be byte-for-byte what the provider sent; do not open and re-save it in an editor that adds a line ending. And the .well-known folder must not be blocked by your server configuration, which some hosting setups do by default because the folder name starts with a dot.

A quick test: open the URL in a private browser window. If you see the file contents, Apple can too. If you get a 404, a login page or a redirect to your homepage, verification will fail.

Step 2: Add the Button to Checkout

Your provider supplies a script or SDK that draws the Apple Pay button and opens the payment sheet. You tell it the amount, the currency (BHD) and a label for your business name. The customer confirms with Face ID or Touch ID, and the SDK hands your page a payment token.

The button only appears where Apple Pay is available. In practice that means Safari on an iPhone, iPad or Mac with a card in Wallet. Recent Apple software versions also let customers on some other browsers complete the payment by scanning a code with their iPhone, but support depends on the provider's SDK, so check its documentation rather than assuming. On Android and most Windows machines, the button simply does not show.

That is expected behaviour, not a bug. It is also why Apple Pay should sit alongside other methods, never replace them. In Bahrain, that means card payments and BenefitPay, which many local customers prefer. Our BenefitPay integration guide covers that side in detail.

Step 3: Charge on the Server, Never Trust the Browser

This is the part that separates a safe checkout from a risky one. The token your page receives is not a payment. It is permission to attempt one. The flow should be:

1. The browser sends the token and the order ID to your server.
2. Your server looks up the order and works out the amount from its own records, not from anything the browser sent.
3. Your server creates the charge with the provider using your secret key, which never leaves the server.
4. Your server marks the order paid only when the provider confirms the charge was captured.

The browser can be edited by anyone with developer tools. If your server accepts an amount from the page, someone can pay 0.100 BHD for a 100 BHD order. If your page marks the order paid when the payment sheet closes, someone can skip the payment altogether.

The same rule applies to webhooks. When the provider notifies your server that a payment succeeded, the safe pattern is to take the charge ID from the notification and fetch the charge from the provider's API to confirm its status and amount. Do not act on the notification body alone.

With Tap, Apple Pay returns a token just like the card form does, so both can share the same server-side charge path. We have set this up with Tap on an online store, and keeping one path for cards and Apple Pay meant one set of checks rather than two.

Step 4: Test Properly Before Going Live

Apple Pay testing has more friction than card testing, because it needs a real Apple device and, for sandbox testing, a test Apple account with test cards added to Wallet. Your provider's documentation will say how its test mode handles Apple Pay. Plan for:

• A successful payment on iPhone Safari and on a Mac, with the order showing as paid and the right confirmation email sent.
• A cancelled payment, where the customer closes the sheet. The order should stay unpaid and the customer should be able to try again.
• A declined payment, with a clear message and no paid status.
• A browser without Apple Pay, where the button must not appear and other methods must still work.
• A delayed or repeated webhook, which must not mark an order paid twice or send two confirmations.

After launch, make one small live payment yourself and refund it. That confirms the domain, keys and settlement are set up for production, not just for test mode.

What It Costs

Apple does not send you a separate bill for accepting Apple Pay on your website. The transaction fees come from your payment provider, under the terms in your merchant agreement, and Apple Pay payments are generally priced like card payments. Ask your provider for its rates in writing and check whether they differ by card type.

The other cost is the integration work. As a guide, our payment integration work starts at 150 BHD for adding a payment method to an existing website, and a full e-commerce checkout with BenefitPay, cards, Apple Pay and Google Pay is 700 BHD. Those prices cover our work only; your provider's fees are separate and paid to them.

Common Pitfalls

The domain is not verified

The most common reason the button never appears. Check that the verification file loads at the exact URL, with no redirect, and that the provider has finished registering the domain. Registration is not always instant.

The wrong domain or subdomain

Apple verifies the exact host name. If you verified example.bh but checkout runs on www.example.bh or shop.example.bh, the button will not show there. Register every host name that displays the button, or move checkout onto one that is registered. The same applies when you move a store to a new domain: the new domain needs its own verification before launch day.

"It doesn't work on my phone"

Often the phone is Android, or the browser is not supported, or there is no card in Wallet. Before raising a ticket, test on an iPhone in Safari with a card added. Then make sure customers who cannot see the button have a clear alternative straight away.

The amount comes from the page

If a developer passes the total from the browser to the charge request "just for now", it tends to stay that way. Insist that the server calculates the amount from the order record.

Mixed keys

Test keys on a live domain, or a public key registered to a different domain, can produce vague errors with nothing to point at the cause. Keep a short note of which keys belong to which environment and domain.

Forgetting refunds

Refunds on Apple Pay payments are made through your provider, just like card refunds. Make sure whoever handles customer service knows where to do it and that your store records the refund against the order.

Apple Pay and BenefitPay Together

For a Bahrain store, the sensible combination is usually cards, Apple Pay and BenefitPay. Apple Pay serves iPhone users who want the fastest checkout. BenefitPay serves customers who prefer to pay from their banking app. Cards catch everyone else. Each needs its own provider approval, but if your provider supports all three, the server-side work can share the same order and confirmation logic.

Label each option plainly. A customer should know whether they are about to pay by card, by Apple Pay or through BenefitPay before they tap.

A Short Checklist

• Provider confirms Apple Pay is enabled for your merchant account in Bahrain.
• HTTPS works on every checkout page.
• Verification file loads at /.well-known/apple-developer-merchantid-domain-association on every host name that shows the button.
• Server calculates the amount and creates the charge; the browser never decides either.
• Webhooks re-fetch the charge before marking anything paid, and are safe to receive twice.
• Success, cancel, decline and unsupported-browser cases tested on real devices.
• One small live payment made and refunded after launch.