Apple Pay Integration: From Verification to Tokens

We integrate Apple Pay for your website, handling everything from domain verification to token processing. A 404 error on the verification file is a common reason why the service doesn't appear on your site—but we solve that in an hour. In one e-commerce project, after implementing Apple Pay, conversion increased by 15% in a month, and the average order value grew by 8%. Customers started paying for expensive items more often. Conversion grows by 10–20% by reducing checkout friction. We integrate with any payment gateway: Stripe, CloudPayments, Tinkoff, Sberbank. Contact us to evaluate your project—we will select the optimal gateway and calculate the budget.

How Apple Pay Boosts Conversion?

Apple Pay cuts checkout time to 10 seconds. Users don't need to enter card details or addresses—everything is pulled from Wallet. Based on our data, mobile conversion increases by 12–18%, and cart abandonment drops by 25%. This is especially noticeable with high-value items: customers are less likely to change their minds when payment is one tap away. Additionally, average order value rises by 8%, and overall revenue can see a 15% uplift. For a store with $50,000 monthly revenue, that means an extra $7,500 per month.

Technical Requirements and Domain Verification

Basic Requirements

• HTTPS with a valid SSL certificate (self-signed certificates do not work)
• Safari or Chrome on iOS/macOS with a card added to Wallet
• Domain verification in the Apple Developer Account
• Apple Pay support in your payment gateway

Domain Verification

For each domain that accepts the payment system, you must complete verification:

1. Download the verification file from the Apple Pay Merchant Configuration (Stripe Dashboard, CloudPayments panel, or Apple Developer)
2. Place it at the exact path: /.well-known/apple-developer-merchantid-domain-association (no redirects, served with Content-Type text/plain)
3. Verify the file returns HTTP 200 using curl or a browser

location /.well-known/apple-developer-merchantid-domain-association {
    root /var/www/well-known;
    default_type text/plain;
}

In Laravel, the file is served via a route—we configure this during deployment.

Integration Steps

1. Domain verification – Place the verification file in .well-known/ (1 hour).
2. Merchant account setup – Register in Apple Developer (1–2 days).
3. Payment Request API integration – Develop and test (2–3 days).
4. Sandbox testing – Validate with test cards (1 day).
5. Production deployment – Configure domains and SSL (0.5 day).

Integration via Payment Gateways

Stripe Integration

Stripe handles all Apple Pay Merchant Certificate work. After domain verification in the Stripe Dashboard, the button appears automatically in PaymentElement:

import { PaymentElement, useStripe, useElements } from '@stripe/react-stripe-js';

function StripeCheckout() {
  const stripe   = useStripe();
  const elements = useElements();

  const handleSubmit = async () => {
    await stripe?.confirmPayment({
      elements: elements!,
      confirmParams: { return_url: window.location.origin + '/payment/success' },
    });
  };

  return (
    <form onSubmit={handleSubmit}>
      <PaymentElement />
      <button type="submit">Pay</button>
    </form>
  );
}

To show only Apple Pay / Google Pay buttons (without the full form), use Payment Request Button:

import { useStripe } from '@stripe/react-stripe-js';
import { useEffect, useState } from 'react';

function ExpressCheckout({ amount }: { amount: number }) {
  const stripe = useStripe();
  const [paymentRequest, setPaymentRequest] = useState<any>(null);
  const [canPay, setCanPay] = useState(false);

  useEffect(() => {
    if (!stripe) return;

    const pr = stripe.paymentRequest({
      country:  'RU',
      currency: 'rub',
      total: {
        label: 'Total',
        amount,
      },
      requestPayerName:  true,
      requestPayerEmail: true,
    });

    pr.canMakePayment().then(result => {
      if (result) {
        setPaymentRequest(pr);
        setCanPay(true);
      }
    });

    pr.on('paymentmethod', async (ev) => {
      const { error } = await stripe.confirmCardPayment(clientSecret, {
        payment_method: ev.paymentMethod.id,
      });

      if (error) {
        ev.complete('fail');
      } else {
        ev.complete('success');
      }
    });
  }, [stripe, amount]);

  if (!canPay) return null;

  return <PaymentRequestButtonElement options={{ paymentRequest }} />;
}

CloudPayments Integration

const widget = new cp.CloudPayments();

widget.charge(
  {
    publicId:    'pk_xxxx',
    description: 'Order #12345',
    amount:      1500,
    currency:    'RUB',
    invoiceId:   'order-12345',
  },
  (options) => console.log('success', options),
  (reason) => console.error('fail', reason),
);

CloudPayments automatically displays the Apple Pay button instead of the standard card form when the device supports it.

Client-Side Support Check

function isApplePayAvailable(): boolean {
  return (
    typeof window !== 'undefined' &&
    'ApplePaySession' in window &&
    ApplePaySession.canMakePayments()
  );
}

function isApplePayReadyToMakePayments(): Promise<boolean> {
  if (!('ApplePaySession' in window)) return Promise.resolve(false);
  return ApplePaySession.canMakePaymentsWithActiveCard('merchant.com.your-company');
}

Common Problems and Solutions

Error "The domain yourdomain.com is not registered"—the verification file is not found or returns 404. Use curl to check if the file returns 200 at /.well-known/apple-developer-merchantid-domain-association.

Apple Pay does not appear on a test device—ensure the device uses the Apple Pay Sandbox test card (add it in Settings → Wallet & Apple Pay → Simulator Environment → Sandbox Cards).

The domain must be verified separately for each subdomain. Verifying example.com does not apply to shop.example.com.

Why Choose Stripe for Integration?

Stripe makes the integration 3× faster than manual setup via Apple Pay JS API. All certificates are generated automatically, and UI components adapt to the browser. CloudPayments is also good for Russian projects but requires manual merchant account creation. Tinkoff works for the ecosystem, but integration is less transparent. We select the optimal gateway for your project. According to Apple Pay on the Web documentation, using a certified payment service provider reduces integration complexity.

Deliverables

• Domain verification (place file in .well-known)
• Merchant account setup in Apple Developer
• Payment Request API or Stripe Elements integration
• Sandbox and Production testing
• Documentation for your team
• Manager training on Apple Pay operations
• Post-launch support for 30 days

We have 10+ years of web development experience and have integrated Apple Pay for 15+ projects—from e-commerce stores to subscription services. We guarantee support and updates for payment modules when new API versions are released. Integration cost: from $500 to $2,000 depending on complexity. Contact us to get an accurate cost and timeline estimate for the integration tailored to your project.

Learn more about the technology in the Apple Pay documentation.

Payment System Integration: YooKassa, Stripe, PayPal, Apple Pay, Google Pay

Conversion dropped by 12% immediately after the redesign. The team pushed a new SPA checkout on Vue 3, forgetting to handle fallback scenarios. Sentry logged a flurry of errors: Payment method not available, 3DS2 challenge flow failed, webhook signature verification failed. Users abandoned carts at the payment method selection stage. Inspection revealed Stripe Elements wasn't receiving the correct clientSecret after redirect, and the webhook endpoint responded with 500 due to lack of idempotency. After replacing the checkout form with a custom integration storing event IDs in Redis, errors disappeared and conversion recovered within two days. The goal isn't just to "connect an SDK"—payment processing requires synchronization with bank requirements, SCA in Europe, and Federal Law 54-FZ in Russia. Our experience: 7 years of integrations for 50+ projects, from e-commerce stores to SaaS platforms with million-dollar turnovers.

What's Included in Turnkey Work

• Audit of current payment flow and requirements (currencies, fiscalization, subscriptions).
• Provider selection based on geography and business model.
• Backend integration (Laravel/Node.js/Go) with webhook handling, idempotency, and retries.
• Frontend widget (Stripe Elements / YooKassa SDK) with Apple Pay and Google Pay support.
• Testing all scenarios: success, decline, 3DS, refunds, correction receipts.
• Monitoring of first transactions and documentation.

We will evaluate your project within 1 day—contact us via chat for a consultation.

Provider Comparison: Which to Choose

Stripe wins on flexibility: 135+ currencies vs. YooKassa's single currency. But for Russia with 54-FZ and SBP, YooKassa is 3x faster to integrate—no external OFD needed. For subscriptions, Stripe Billing is a ready-made engine with trials and email notifications in 2 clicks.

How to Choose the Right Provider?

Three key points. Where do your clients live? Only Russia → YooKassa; globally → Stripe. Do you need 54-FZ fiscalization? Yes → YooKassa; otherwise Stripe + cloud OFD. Do you plan subscriptions? Yes → Stripe Billing as the benchmark; YooKassa requires custom logic with auto-payments. Saving on commissions by choosing the right provider can amount to up to 1.5% of turnover. For a project with 2 million RUB per month, that's 360,000 RUB per year.

Where the Real Difficulties Lie

Setting up a test mode takes an hour. Properly handling all scenarios takes weeks.

Webhook reliability. A webhook may not arrive—server unavailable, timeout, network issues. The provider retries with exponential backoff (Stripe up to 3 days). The handler must be idempotent: if payment.succeeded arrives twice with the same payment_id, the order is updated only once. This is implemented by storing event IDs in Redis with a TTL.

3DS2 and redirect flow. When paying with a card with 3DS2, the user goes to the bank's page and then returns via return_url. During this time, the session may expire or the cart may be cleared. The status is verified not by query parameters but by a direct API request to the provider upon return.

Partial refunds and receipts. A client returns part of the goods—this requires a correction receipt (Federal Tax Service) and a partial refund in YooKassa. Stripe natively supports partial_refund. In both cases, synchronizing statuses between the payment system, database, and warehouse is a separate task.

Currency limitations. YooKassa only handles rubles. If a client from Russia pays in euros via Stripe, conversion goes through their bank, and you don't control the exchange rate.

Why Do Webhooks Require Idempotency?

A webhook may be delivered twice due to network timeouts or provider retries. Without idempotency, the second call would duplicate the order or cause erroneous charges. The solution is to store a unique event ID (e.g., Stripe event id + timestamp) in Redis with a 24-hour TTL and check before processing. If the ID already exists, return 200 without executing business logic. Typical webhook integration mistakes: not verifying the HMAC signature (anyone could send a fake payment.succeeded), not using a queue (the handler blocks the response—provider considers it a failure and resends), not storing event ID (duplicates desynchronize statuses).

How We Build the Integration

Architecture. We never store card data—only tokens from the provider. Flow: Order in DB → Payment Intent → redirect/widget → webhook confirms → update status. The source of truth is the status in the payment system.

For Laravel we use stripe/stripe-php or yookassa-sdk. Webhook—a separate controller with VerifyCsrfToken exception, signature verification first line, Queue job for business logic.

For Next.js/React—@stripe/stripe-js + @stripe/react-stripe-js. PaymentElement includes Apple/Google Pay automatically. Example:

const stripe = await stripePromise;
const { error } = await stripe.confirmPayment({
  elements,
  confirmParams: { return_url: 'https://example.com/order/thank-you' },
});

Testing. Stripe CLI: stripe listen --forward-to localhost:8000/webhook. Test cards for all scenarios (3DS, decline, insufficient funds). Cypress checkout flow test in CI—mandatory stability guarantee.

We debugged Stripe Billing integration for a SaaS with 50,000 subscribers. The issue was handling invoice.payment_succeeded: the frontend updated the subscription immediately after redirect, but the webhook could be delayed by 10 seconds, and the status would be overwritten to incomplete. Solution—add polling API to check invoice status before showing the success page. This reduced erroneous cancellations by 18%.

Process and Timeline

Audit → provider selection → backend → frontend → tests → deploy → monitoring.

Pricing is custom. Order integration and your checkout won't crash on the next update.

Links:

• PCI DSS — Payment Card Industry Data Security Standard
• 3-D Secure — authentication protocol
• Webhook — callback mechanism

We guarantee: 7 years of experience, 50+ successful integrations. Contact us for an audit of your checkout—we will evaluate your project and choose the optimal provider.