Integrating Express Checkout Options in Magento 2

1. Why express checkout options lower the abandonment rate

The classic Magento checkout with address entry, shipping selection and payment data is necessary for first time buyers, but unnecessarily slow for returning customers or mobile users with saved wallets. Express checkout options skip exactly this repeated data entry by carrying already available information from Apple Pay, Google Pay, or a saved Magento customer account directly into a finished order, often with just a single tap on a smartphone.

The effect on conversion is substantial in practice, especially on mobile devices, where long forms with a virtual keyboard are the biggest source of purchase abandonment. An express checkout option such as Apple Pay fills in address, payment method, and sometimes even billing data from the operating system wallet, without the customer touching a single text field.

This article covers the three central express checkout options for Magento 2: the native Instant Purchase module for returning, logged in customers, express payment buttons for Apple Pay and Google Pay on product and cart pages, and the technical integration of both approaches into a Hyvä frontend, including security aspects and conversion measurement.

2. The three building blocks of express checkout options

The first building block is Instant Purchase, a native Magento module that offers logged in customers with a saved default address and default payment method a single order button directly on the product page. The second building block is express payment buttons, which use wallet APIs such as the Apple Pay JS API or the Google Pay API to enable fast payment with data stored in the operating system, even for first time buyers without a Magento account. The third building block is consistently carrying over address and payment data from these sources into the Magento quote, without losing the reduced checkout scope.

All three building blocks share one thing: they do not replace the regular checkout process, they offer a faster shortcut alongside it. A solid express checkout option must therefore go through the same server side validation rules as the normal checkout, just without the customer manually clicking through these steps in the frontend.

For Hyvä projects, that means concretely: the express buttons themselves are small, self contained Alpine.js components with a thin Magewire connection that calls the same service contracts in the background as the regular checkout, in particular CartManagementInterface and PaymentInformationManagementInterface.

3. Activating and adjusting Magento Instant Purchase

Instant Purchase is part of the core module Magento_InstantPurchase and is available to logged in customers as soon as at least one saved address and one saved, tokenized payment method exist. The eligibility check, whether a customer may even see the Instant Purchase button at all, runs through a chain of EligibilityCheckerInterface implementations, which among other things check whether the saved payment method is still valid and whether the product can even be ordered without further configuration, for example having no required options without a preselection.

For project specific requirements, this eligibility chain can be extended with a custom checker, without replacing the native logic. A typical use case: Instant Purchase should not be offered for products with limited availability, or for customers without a confirmed email address, even though the native eligibility check sees no reason for that.

<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
    <type name="Magento\InstantPurchase\Model\EligibilityChecker\CompositeEligibilityChecker">
        <arguments>
            <argument name="checkers" xsi:type="array">
                <item name="mironsoft_verified_email" xsi:type="object">Mironsoft\ExpressCheckout\Model\EligibilityChecker\VerifiedEmailChecker</item>
            </argument>
        </arguments>
    </type>
</config>

<?php

declare(strict_types=1);

namespace Mironsoft\ExpressCheckout\Model\EligibilityChecker;

use Magento\Customer\Model\Customer;
use Magento\Framework\Exception\LocalizedException;
use Magento\InstantPurchase\Model\EligibilityChecker\EligibilityCheckerInterface;

/**
 * Excludes customers without a verified email address from the native
 * Instant Purchase eligibility chain, without replacing any native check.
 */
class VerifiedEmailChecker implements EligibilityCheckerInterface
{
    /**
     * @param Customer $customer
     * @return bool
     * @throws LocalizedException
     */
    public function isEligible(Customer $customer): bool
    {
        return (bool) $customer->getData('is_email_verified');
    }
}

The custom checker implements EligibilityCheckerInterface with a single isEligible() method, which receives the current product alongside the customer. This express checkout option stays additively extensible this way, without requiring a preference on the native eligibility chain, which keeps Magento upgrades unproblematic.

4. Express payment buttons on product and cart pages

While Instant Purchase serves only logged in customers with saved data, express payment buttons for Apple Pay and Google Pay target all visitors, even without a Magento account. These buttons use the respective operating system wallet API to query address and payment data directly from the device, transmit it encrypted to the payment gateway provider, and only afterwards create an order in Magento.

Technically this creates a trade off: the actual wallet communication runs client side via JavaScript APIs outside the control of the Magento backend. The express checkout option must therefore be treated server side exactly like any other payment method, including full validation through the service contract plugins described in the previous article, before the order is actually created.

5. Integrating express buttons as a Magewire component into Hyvä

For a Hyvä project, the express payment button is implemented as a standalone Alpine.js component that initializes the respective wallet API when the product page loads and shows the button if available, otherwise staying hidden. This availability check is important: Apple Pay is only available in Safari on supported devices, Google Pay only with a correspondingly configured browser and device, an express checkout option without this check would show non functional buttons.

<div x-data="expressPayment()" x-init="checkAvailability()" x-show="isAvailable" class="mt-4">
    <button type="button" @click="startExpressPayment()"
            class="w-full bg-black text-white rounded-lg py-3 font-semibold flex items-center justify-center gap-2">
        <span x-text="walletLabel"></span>
    </button>
    <p x-show="errorMessage" x-text="errorMessage" class="text-red-600 text-sm mt-2"></p>
</div>

<script>
function expressPayment() {
    return {
        isAvailable: false,
        walletLabel: '',
        errorMessage: '',
        checkAvailability() {
            // Feature detection runs entirely client side, no server call needed
            if (window.ApplePaySession && ApplePaySession.canMakePayments()) {
                this.isAvailable = true;
                this.walletLabel = 'Pay with Apple Pay';
            } else if (window.google && window.google.payments) {
                this.isAvailable = true;
                this.walletLabel = 'Pay with Google Pay';
            }
        },
        startExpressPayment() {
            this.$wire.initiateExpressPayment(this.walletLabel).then((result) => {
                if (!result.success) {
                    this.errorMessage = result.message;
                }
            });
        }
    };
}
</script>

Clicking the button triggers the operating system's wallet selection client side, the result is then passed to a server side component via a Magewire call that creates an order from the encrypted wallet token. This express checkout option stays consistent this way with the rest of the checkout's Magewire architecture.

6. Carrying over address and payment data from wallets

A central advantage of every express checkout option is the automatic transfer of address and contact data from the wallet, without the customer typing anything. The wallet APIs return this data in a vendor specific JSON format that must be translated server side into the Magento address format, including country code mapping and splitting a single name field into first and last name.

{
  "shippingContact": {
    "givenName": "Anna",
    "familyName": "Schmidt",
    "addressLines": ["Musterstraße 12"],
    "locality": "Berlin",
    "postalCode": "10115",
    "countryCode": "DE",
    "emailAddress": "anna.schmidt@example.com"
  },
  "paymentToken": {
    "provider": "apple_pay",
    "encryptedData": "base64-encoded-payload-not-a-real-token"
  }
}

The following service performs exactly this translation. Important here: the encrypted paymentToken is never parsed or stored itself, it is passed on unchanged to the payment gateway command, which has it decrypted at the external payment provider.

<?php

declare(strict_types=1);

namespace Mironsoft\ExpressCheckout\Model;

use Magento\Quote\Api\Data\AddressInterface;
use Magento\Quote\Api\Data\AddressInterfaceFactory;

/**
 * Translates wallet API shipping contact payloads into Magento quote
 * address objects, without touching the encrypted payment token.
 */
class WalletAddressMapper
{
    /**
     * @param AddressInterfaceFactory $addressFactory
     */
    public function __construct(
        private readonly AddressInterfaceFactory $addressFactory
    ) {
    }

    /**
     * @param array{
     *     givenName: string,
     *     familyName: string,
     *     addressLines: string[],
     *     locality: string,
     *     postalCode: string,
     *     countryCode: string
     * } $shippingContact
     * @return AddressInterface
     */
    public function mapToQuoteAddress(array $shippingContact): AddressInterface
    {
        $address = $this->addressFactory->create();
        $address->setFirstname($shippingContact['givenName']);
        $address->setLastname($shippingContact['familyName']);
        $address->setStreet($shippingContact['addressLines']);
        $address->setCity($shippingContact['locality']);
        $address->setPostcode($shippingContact['postalCode']);
        $address->setCountryId($shippingContact['countryCode']);

        return $address;
    }
}

7. Security aspects of express checkout options

An express checkout option reduces friction, but must not lose any security level compared to the regular checkout. The most important principle: payment data from Apple Pay or Google Pay arrives at the merchant already tokenized and encrypted, the plaintext card format never leaves the operating system wallet. Magento itself only ever processes the encrypted token and passes it on to the payment gateway command, as described in the previous article on payment method integration.

In addition, every express checkout option should go through the same fraud check as a regular order. A shortened checkout path must never mean fraud rules, address validation, or stock checks get skipped just because the customer filled in fewer form fields. Server side, the same plugins on CartManagementInterface::placeOrder run that the regular checkout also goes through, regardless of whether the order was triggered via an express button or the classic form.

8. Conversion measurement and A/B tests

Whether an express checkout option actually improves conversion can only be judged with clean tracking. Every express button should trigger its own analytics event that distinguishes between a click, a successful wallet dialog, and an actually completed order. Without this granularity, it is impossible to tell whether customers click the button but abort the wallet dialog, which would indicate a technical problem rather than a lack of interest.

An A/B test that varies the position and visibility of the express checkout option on the product page, for example above versus below the regular add to cart button, often delivers surprisingly clear differences in click rate. It is important to consistently distinguish between mobile and desktop users in such tests, since wallet buttons are generally adopted much more strongly on mobile devices than on desktop.

9. Express checkout approaches compared

The following table compares the three approaches covered along the criteria relevant to a project.

In practice, the approaches do not exclude each other. A well set up shop offers Instant Purchase for repeat customers, express payment buttons for all mobile visitors, and the classic checkout as a complete fallback, with all three paths relying server side on the same validated order logic.

10. Summary

Effective express checkout options in Magento 2 consist of three complementary building blocks: Instant Purchase for logged in repeat customers with saved data, wallet buttons such as Apple Pay and Google Pay for all mobile visitors, and the classic checkout as a complete fallback. Every express variant must go through the same server side validation and fraud rules as the regular checkout, just without the customer manually clicking through the individual steps.

The biggest lever for conversion lies in the clean technical integration of the wallet APIs into the Hyvä frontend as standalone Alpine.js and Magewire components, combined with granular conversion tracking that distinguishes between click, wallet dialog, and completed order. Whoever consistently implements and measures these express checkout options noticeably reduces purchase abandonment, especially on mobile devices.

11. FAQ: Express Checkout Options in Magento 2