Learn SAP from the Experts | The SAP PRESS Blog

What Is the SAP Digital Payments Add-On?

Written by SAP PRESS | Jun 29, 2026 1:00:02 PM

The digital payments add-on was introduced in 2017, as a cloud-based software-as-a-service (SaaS) offering, hosted on SAP BTP.

 

The solution fundamentally changes how organizations integrate payment processing with SAP applications.

 

Rather than building and maintaining point-to-point connections between SAP systems and individual PSPs, the digital payments add-on provides standardized middleware that handles complexity centrally while reducing the PCI compliance scope for SAP environ­ments.

 

The add-on operates as an intermediary infrastructure between consumer applications and PSPs. Consumer applications including SAP S/4HANA, SAP Commerce Cloud, SAP Subscrip­tion Billing, or custom applications initiate payment operations by calling standard digital payments add-on APIs. The add-on then orchestrates communication with appropriate PSPs based on configuration rules, handles data transformation between application for­mats and PSP requirements, manages tokenization to protect sensitive payment data, and returns the payment results to calling applications.

 

The add-on’s cloud-based architecture provides several advantages over traditional point-to-point integrations, as follows:

  • SAP maintains and upgrades the core infrastructure, eliminating customer responsibility for server management, security patching, and capacity planning.
  • The multitenant SaaS model distributes costs across subscribers rather than requiring a dedicated infrastructure for each customer.
  • Elastic scalability automatically adjusts to transaction volume fluctuations without man­ual intervention.
  • Geographic distribution across SAP BTP data centers provides high availability and disaster recovery capabilities built into the service.

In addition, the deployment model keeps sensitive payment data outside customer SAP systems entirely. When customers enter payment card information, that data flows directly to PSPs through the digital payments add-on without touching SAP systems. The add-on returns tokens, randomly generated identifiers with no intrinsic value, which SAP applica­tions store instead of actual card numbers. This architectural decision fundamentally reduces the PCI DSS compliance scope for SAP environments.

 

The token vault is a piece of critical infrastructure within the digital payments add-on. When customers register payment cards, the digital payments add-on forwards card details to the PSP, which returns a network token from Visa Token Service or Mastercard Digital Enablement Service. The add-on stores this token in its secure vault and provides an add-on-specific reference token to calling applications. This two-tier tokenization architecture ensures that even compromising the digital payments add-on vault would not expose usable payment credentials.

 

Token lifecycle management handles scenarios beyond simple storage. The add-on han­dles these lifecycle events through APIs that consumer applications invoke as needed:

  • Tokens can be updated when underlying card details change. Card networks provide token update services that propagate new expiration dates or replacement card num­bers without customer interaction.
  • Tokens can be suspended if fraud is suspected, preventing their use without deleting the token entirely.
  • Tokens can be deleted when customers remove payment methods or close accounts.

The adapter framework isolates consumer applications from PSP specifics. Each PSP main­tains proprietary APIs with different authentication mechanisms, data structures, error codes, and operational characteristics. Direct integration requires custom code for each PSP, multiplying development and maintenance effort. The digital payments add-on abstracts these differences through standardized adapters.

 

Each adapter implements standard interfaces defined by the digital payments add-on while handling PSP-specific communication requirements internally. When consumer applications request payment authorization, they call a generic digital payments add-on API without specifying which PSP to use. The add-on determines the appropriate PSP based on merchant mapping rules, invokes the corresponding adapter with standardized parameters, and translates responses into a uniform format for the calling application. This architecture provides substantial benefits:

  • Organizations can switch PSPs by changing their configuration rather than modifying application code.
  • Multiple PSPs can be supported simultaneously for different regions, business units, or payment methods.
  • New PSP adapters become available through SAP and partners without requiring changes to consumer applications.
  • Organizations reduce vendor lock-in because payment logic remains independent of specific PSP implementations.

If you need partners to create adapters for PSPs not yet certified by SAP, the adapter devel­opment kit allows you to do so. This extensibility ensures that organizations can integrate with regional or specialized PSPs as business requirements demand. Partners certify adapt­ers through SAP’s certification process, providing quality assurance and compatibility guar­antees for customers.

 

PSPs communicate transaction updates through webhooks, HTTP callbacks triggered by payment events. When a payment status changes—an authorization expires, a chargeback is filed, a payment completes settlement—the PSP sends a webhook notification to config­ured endpoints. The digital payments add-on provides webhook management infrastruc­ture that consumer applications leverage.

 

Webhook endpoints require several technical considerations: URLs must be publicly acces­sible so that PSPs can reach them, requiring appropriate firewall and network configura­tion. Endpoints must authenticate webhook requests to prevent spoofing—typically through signature validation using shared secrets. Processing must be idempotent because PSPs may send duplicate notifications, requiring applications to handle repeat events gracefully. High availability becomes critical because missed webhooks may require man­ual intervention to reconcile payment state.

 

The digital payments add-on handles these technical requirements centrally. Organiza­tions configure webhook endpoints once in the add-on, which then manages signature val­idation, duplicate detection, and reliable delivery to consumer applications. This central­izes expertise and infrastructure rather than requiring each consumer application team to implement webhook handling independently.

 

When it comes to certifications and support, the add-on has PCI DSS Service Provider Level 1 certification, the highest validation level, requiring annual audits by Qualified Security Assessors. This certification covers the entire digital payments add-on infrastructure, including the token vault, API layer, PSP adapter framework, and webhook processing. Cus­tomers benefit from this certification without maintaining separate PCI environments or conducting separate assessments for payment infrastructure.

 

API authentication uses industry-standard OAuth 2.0 with service-to-service flows appro­priate for system-to-system integration. Consumer applications first obtain bearer tokens from SAP BTP identity services, then include these tokens in API requests. The digital pay­ments add-on validates tokens, checks authorization for requested operations, and pro­cesses requests only after successful authentication and authorization. This prevents unau­thorized access even if network-level controls fail.

 

The digital payments add-on and certified PSP adapters support extensive payment method coverage, spanning traditional cards, digital wallets, alternative payment meth­ods, and real-time payment rails. The specific methods available depend on PSP selection and geographic markets served. Card payment support includes major global networks: Visa and Visa Electron, Mastercard and Maestro, American Express, Discover and Diners Club, JCB (Japan), and UnionPay (China).

 

Digital wallet support varies by PSP but commonly includes Apple Pay, Google Pay, PayPal, Samsung Pay, Alipay, and WeChat Pay. These wallets require network tokenization support—a capability that certified PSP adapters provide through integration with Visa Token Service, Mastercard Digital Enablement Service, and proprietary wallet-tokenization systems.

 

Global companies require payment processing across multiple currencies with appropriate FX handling. The digital payments add-on supports multicurrency scenarios through PSP determination logic and merchant account configuration. Organizations can configure dif­ferent merchant accounts for different currencies.

 

The digital payments add-on also maintains compliance with relevant payment industry standards and regulations:

  • Strong Customer Authentication compliance for European transactions implements PSD2requirements through 3D Secure 2.0 protocol integration. When processing European card payments, the add-on triggers authentication flows that collect two of three authentica­tion factors—knowledge (password), possession (phone), or inherence (biometric).
  • GDPR compliance addresses personal data handling for European customers. The add-on provides data subject access request capabilities, allowing individuals to retrieve their stored payment tokens, use data deletion APIs for right-to-be-forgotten requests, and have data processing agreements establishing SAP’s role as data processor rather than controller.
  • Regional certifications vary by PSP. Cybersource holds certifications across multiple regions, including North America, Europe, Asia-Pacific, and Latin America. Adyen main­tains licenses in jurisdictions worldwide. Organizations selecting PSPs must verify the coverage for markets they serve, ensuring the PSP adapter combination supports required capabilities in each geographic area.
  • The multi-PSP architecture provides compliance redundancy. If one PSP encounters reg­ulatory issues in a specific market, then organizations can route transactions through alternative certified providers without system downtime. This redundancy particularly matters for global operations in which regulatory landscapes evolve differently across jurisdictions.

Enterprise-Grade Availability, Performance, and Support Service-Level Agreements

As a cloud service, the digital payments add-on operates within defined service-level agreements (SLAs) that cover availability, performance, and support. SAP schedules maintenance during low transaction periods and provides advance notice for planned maintenance. Unplanned outages trigger incident management processes, with prior­ity based on business impact.

 

Transaction volume limits exist per merchant account and overall tenant. PSPs also impose velocity limits, preventing rapid-fire transactions that might indicate fraud or system errors. The digital payments add-on enforces configured throttling limits, rejecting requests that exceed established thresholds.

 

Support follows SAP’s standard incident management processes: Organizations report issues through SAP Support Portal to be analyzed when problems originate in their sys­tems and get resolution.

 

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 6/2026.