The SAP digital payments add-on is a cloud-based middleware component hosted on SAP BTP.
Its primary role is to act as a centralized payment hub that decouples business applications—SAP or non-SAP—from the complexity of integrating with multiple PSPs. By serving as this central hub, the add-on unifies communication protocols and manages a broad range of payment activities, including sales order authorization, settlement, invoice and refund handling, payment advice reconciliation, and pay-by-link scenarios. The result is a single, secure gateway (see figure below) through which all digital payment transactions that touch your SAP landscape are processed and monitored.
At its core, the architecture positions the add-on service between consumer applications—such as SAP ERP, SAP S/4HANA, SAP Subscription Billing, or other, non-SAP solutions on the one hand, and external PSPs like Stripe, PayPal, SnapPay, Worldpay B2B Payments, and the like on the other. This layered arrangement delivers the key advantage of the add-on: Business applications interact through a single, consistent API interface, while the add-on handles the individual PSP integrations and routing logic behind the scenes.
Logically, the architecture has three main layers or component groups.
This layer provides secure APIs, which SAP and non-SAP applications use to initiate and manage payment transactions. Its key characteristics include the following:
This table lists available API operations commonly used in customer landscapes.
| Available API Functions | ||
| Card registration | Card deletion | Refund |
| Authorization | Reauthorization | Payment advice |
| Capture | Settlement | |
This is the central engine running on SAP BTP. It receives requests from consumer applications, performs routing determination, orchestrates the end-to-end payment flow, and manages security. This table lists the primary responsibilities.
| Routing Engine | Transaction Orchestration | State Management |
|
Dynamically selects PSP and merchant account based on the following:
|
Orchestrates the end-to-end payment flow:
|
Manages transaction state and security:
|
These components are deployed alongside the core service on SAP BTP. They are responsible for translating the standardized requests from the add-on core into PSP-specific protocols and message formats. This table lists several common PSP adapters, together with their key functions and responsibilities.
| Adapter Responsibilities | Common PSP Adapters |
|
|
A notable concept in this architecture is the use of merchant ID aliases. Each technical PSP merchant account is linked to a user-friendly alias configured within the consumer application (e.g., a virtual bank account). These aliases connect the add-on’s routing logic with the application’s financial structure, enabling accurate reconciliation and simplified maintenance.
This architectural approach has significant benefits, as follows:
Consumer applications can connect with the add-on’s APIs without developing or maintaining multiple point-to-point connections with various PSPs. This table compares the traditional, tightly coupled model with the add-on-based approach.
| Integration Complexity (Traditional Approach) | Simplified Integration (Add-On Approach) |
|
|
The add-on consolidates connectivity management, credential handling, and PSP monitoring in one place. This reduces the administrative effort required from application teams. SAP takes care of the operation and maintenance of the cloud service based on defined service-level agreements (SLAs). This table shows how this approach minimizes operational overhead compared to decentralized models.
| Operations Burden (Traditional Approach) | Centralized Operations (Add-On Approach) |
|
|
Through tokenization, sensitive payment data, such as cardholder information, never traverses or resides within business systems (e.g., SAP S/4HANA). This greatly reduces the PCI DSS compliance requirements for the core ERP system. The add-on insulates the application from costly audit and security requirements, serving as a protective compliance layer. This table shows the compliance impact of both traditional and add-on architectures.
| Compliance Risk (Traditional Approach) | Enhanced Security (Add-On Approach) |
|
|
Adding new PSPs or switching between them is much simpler. You only need to configure the add-on instead of making major changes to consumer applications, and fewer changes means less retesting of payment flows, which are typically hard to simulate in nonproduction environments. Test cards and test PSP environments do not accurately reflect the end-to-end payment flows in production, where live credit cards are used.
In addition, when businesses expand into new markets, they need new payment methods and payment flows to be supported rapidly in order to get new customers. The cloud-native architecture on SAP BTP offers built-in scalability, allowing businesses to scale horizontally and vertically; that is, they can manage sudden increases in transaction volumes during the peak season or inorganic growth through a major acquisition. This table shows a comparison of the flexibility benefits of the add-on-based approach compared to the traditional approach.
| Limited Flexibility (Traditional Approach) | Maximum Flexibility (Add-On Approach) |
|
|
The SAP digital payments add-on replaces a web of point-to-point PSP connections with a single service on SAP BTP that handles routing, orchestration, and security on behalf of your business applications. That separation is what delivers the practical benefits: one API for developers, provider onboarding as a configuration task rather than a project, and cardholder data tokenized so it never lands in SAP S/4HANA. The design decisions that remain, such as how merchant ID aliases map to your financial structure, are the ones worth spending time on before you connect your first provider.
Editor’s note: This post has been adapted from a section of the book Digital Payments with SAP: Credit Card Processing, PSP Integration, and PCI Compliance by Saravana Kumar Kuppusamy. Saravana has more than 24 years of experience with SAP implementation and global rollout projects, as well as 10 years of experience managing payment platforms. He has led payments modernization initiatives, migrating from legacy payments processing solutions to the SAP digital payments add-on. He has architected the entire modernization effort across SAP ERP, SAP S/4HANA, and SAP BTP for both B2B and B2C commerce environments. His experience includes technical implementations, PSP integrations, PCI compliance, tokenization strategies, fraud management, and production deployment.
This post was originally published 9/2026.