Amazon Pay for TYPO3

Amazon Pay reduces checkout abandonment because customers do not need to create a new account

A large share of German online shoppers have an Amazon account. When these users click “Buy” in a TYPO3 shop and see a registration form with 12 mandatory fields, many abandon. Amazon Pay solves this problem: the customer authenticates with their Amazon account, delivery address and payment method are transferred automatically. No form, no credit card number, no new password. According to a comScore study commissioned by Amazon Pay (USA, 40 merchants), conversion with Amazon Pay was on average 35% higher than with the merchants’ own checkout.

For TYPO3 shop operators, the integration is not plug-and-play. Amazon Pay requires an API connection (Amazon Pay API v2), shop domains registered in Seller Central and regular security updates. Amazon reviews the domains against its Acceptable Use Policy before go-live.

Typical use cases

Mid-market B2C shops with aimeos. Online shops for fashion, electronics, household goods that want to offer a third payment method alongside PayPal and credit card. Amazon Pay works particularly well for impulse-driven purchases under 200 EUR, where every hurdle in the checkout directly costs revenue. The integration into aimeos runs through a custom service provider that hooks into the payment pipeline.

Donation platforms and membership fees. Associations and NGOs that collect donations or membership fees through their TYPO3 website benefit from the low entry barrier. The donor clicks “Pay with Amazon”, confirms the amount and is done. No IBAN entry, no direct debit setup. For recurring payments, Amazon Pay supports Recurring Payments.

Digital products and downloads. Software licenses, e-books, online courses - products without physical shipping benefit especially, because the entire purchase process needs no input into a shop form. No shipping address needed, only authentication and payment.

Technical architecture

Amazon Pay v2 is based on a REST API with JSON payloads. The flow in a TYPO3 shop: the customer clicks the Amazon Pay button, is redirected to Amazon (or a popup opens), logs in and confirms address and payment method. Amazon redirects back to the shop with the ID of the checkout session created when the button was clicked. The shop adds the amount and order details to the checkout session via the Amazon Pay API. After confirmation by the customer, the payment is triggered.

The integration into TYPO3 requires three components: an API client (HTTP requests to the Amazon Pay API with RSA key signature), a frontend component (Amazon Pay button as JavaScript widget) and a webhook handler for asynchronous notifications (payment confirmation, refund, chargeback).

For aimeos, the documentation lists no Amazon Pay provider; the connection is built as a custom service provider. For tt_products or custom shops, a dedicated integration is required. In both cases, the TYPO3 shop must use HTTPS (mandatory for the IPN endpoint in production), and the webhook URL must be externally reachable.

Amazon provides a sandbox environment where all payment flows can be tested without real money. The sandbox uses dedicated API endpoints and test accounts.

Common problems and solutions

Go-live checklist incomplete. Before go-live, the shop tests success and failure cases in the sandbox and works through Amazon’s checklist: button placement, error handling for declined payments, display on mobile devices, correct cancellation flow. Common errors: the Amazon Pay button does not appear on the product page (only in the cart), error messages for payment declines are missing or in the wrong language. Solution: work through Amazon’s pre-launch checklist completely before the shop goes live.

IPN notifications (Instant Payment Notifications) are lost. Amazon sends payment confirmations asynchronously via POST to a registered URL. If TYPO3 blocks these requests through caching, redirect rules or missing CSRF exceptions, the order remains in “pending” status. Solution: set up a dedicated eID route or middleware route for the webhook that runs outside normal TYPO3 request processing.

Recurring Payments and subscription models. Amazon Pay supports recurring payments, but setup is more complex than with Stripe Subscriptions. The customer must agree to a recurring Charge Permission at checkout, and the shop triggers each due payment with Create Charge. Solution: manage Charge Permissions as a dedicated database entity and set up a cronjob that triggers due payments.

Migration and version compatibility

Amazon Pay v2 is the current API version (since 2020). Amazon recommends version 2 for new integrations. Existing v1 implementations still work but receive no updates and no new features. Migrating from v1 to v2 affects the entire API client: different endpoints, different signature mechanism (RSA instead of HMAC), different session management.

For TYPO3, there is no official Amazon Pay extension in the TER with active v12/v13 support. Integration is done as custom code, in aimeos as a custom service provider. Gosign implements Amazon Pay as a standalone Composer package that can be integrated into any TYPO3 shop setup. This package encapsulates the API client, the button and the webhook handler, so a TYPO3 major upgrade only affects the TYPO3-specific adapter layer.

For shop operators offering PayPal, credit card and Klarna alongside Amazon Pay, Gosign recommends a unified payment abstraction. Instead of integrating each provider individually, a common interface is implemented through which all payment providers are addressed. aimeos brings this abstraction natively (service provider architecture). For custom shops, Gosign builds a comparable layer that decouples checkout code from provider-specific APIs. This reduces the effort for new payment providers to implementing a single adapter instead of a complete integration.

The total cost of an Amazon Pay integration in an existing TYPO3 shop is 3 to 8 development days, depending on whether the shop runs on aimeos with its provider interface or a custom integration is needed. Sandbox tests and the go-live checklist require an additional 1 to 2 days for preparation and correction rounds.