How to Integrate SAP Digital Payments into Your E-Commerce Architecture

Behind every seamless online payment stands a complex integration of systems, data, and processes — here’s how we built it for a global B2B leader using SAP Digital Payments.

In the first part of our series, we explained what SAP Digital Payments (SAP DP) is and highlighted its business value for companies managing payments across multiple markets.

Now, in the second part, we open the “technical kitchen.” We will show how to actually integrate SAP DP with an e-commerce system and design workflows that ensure security, flexibility, and compliance — all without disrupting the customer journey.

To make this tangible, we take you behind the scenes of a real project we delivered for one of our clients: a global B2B giant running e-commerce operations in numerous local markets. The company needed a solution that could flexibly adapt payment methods and providers to each country’s specific business and regulatory requirements.

Why is this topic so important? Because payments in e-commerce are among the most complex processes to handle. They involve user experience, order management in the backend, ERP accounting, reconciliation, regulatory compliance, and customer service. A single weak link can lead to serious operational and financial risks. And in B2B — where order values are often much higher than in B2C — the stakes are even greater.

Through the intricacies of SAP Digital Payments, we will be guided by our expert — Damian Woźniak, Technical Architect at Striped Giraffe.

Two Integration Models

As we mentioned in the first part of this series, there are two integration models that SAP offers to connect an e-commerce platform with SAP Digital Payments:

1. Payment Page
2. Direct PSP Connection

Both models have different implications for architecture, user experience, and operational processes. Our customer decided to implement and test both approaches to evaluate their strengths and weaknesses.

Model 1: Payment Page

The Payment Page model is PSP-agnostic. This means that the e-commerce application does not need to know which specific payment service provider (PSP) is being used. The entire customer payment process is handled through SAP DP interfaces.

Once a payment transaction is completed, all required payment data is retrieved from SAP DP and sent along with the order data to the SAP S/4HANA system. SAP S/4HANA can then execute further actions for the transaction, such as refunds.

Figure 1. SAP DP Payment Page Integration Model

SAP provides a JavaScript library called DPJSLIB. It is responsible for rendering the payment page in a dedicated window. The content inside this window is served directly by the integrated PSP. This means that every new PSP integration requires coordination with the PSP team to build such a page according to business and UX/UI requirements.

DPJSLIB also enables the application to load all available payment methods configured in the SAP DP administration panel. Based on these options, the user can select the payment method they prefer.

In addition, SAP provides REST endpoints that allow the integrated system to initiate a payment transaction and check its status.

Model 2: Direct PSP Connection

In the Direct PSP Connection model, the e-commerce application integrates directly with a specific PSP, without SAP DP in the middle of the transaction process. SAP DP operates only on the backend layer, supporting financial operations after the order has been placed.

SAP DP is informed about transactions executed directly with the PSP via dedicated endpoints exposed by SAP. These are used to pair the transaction with SAP DP through an adapter.

In this model, the entire payment process is controlled by the PSP. As a result, the UI and overall user experience depend on the PSP chosen.

Figure 2. SAP DP Direct PSP Integration Model

Integrating SAP DP Payment Page with the E-commerce System

Since our client already operated on SAP Commerce, this project was based on that platform. Still, it’s important to note that the same approach could be successfully implemented with other e-commerce systems such as Adobe Commerce/Magento, Shopify or Salesforce Commerce Cloud.

Step 1: Loading Payment Methods

We injected the DPJSLIB script into the frontend application. This is a mandatory step to load digital payment methods and render the payment page served by the PSP.

Step 2: Communication with SAP DP

To communicate with SAP DP endpoints, we developed a REST service (Microservice #1). This centralized unit manages all communication and is especially useful when planning to integrate multiple applications across the architecture landscape with SAP DP.

The service connects to AWS Secret Manager, where SAP client credentials are securely stored. Importantly, the commerce system itself is not connected to the PSP directly. This separation makes it easier to maintain and switch PSPs based on business needs.

Figure 3. Payment Page Solution Architecture

Step 3: Order Placement in ERP

Microservice #1 and SAP Commerce work together to check payment transaction status. In case of success, they trigger order placement.

To place an order in SAP ERP, we leveraged an existing middleware REST service (Microservice #2), which we customized to meet the project’s requirements. This service is responsible for various order-related actions and can be called by SAP Commerce when needed.

Step 4: Communication Flow

The frontend communicates with Microservice #1 and SAP Commerce via GraphQL. This wrapper simplifies data aggregation and API call execution.

Figure 4. Payment Page Sequence Flow

(Hover over the diagram to zoom into specific areas. A high-resolution version is also available for download in PDF and PNG formats.)

How the Payment Page Flow Works

1. Checkout page opens

The customer navigates to the checkout page, which requires payment to complete the order. At this stage, the frontend simply renders the already available content.

2. Initiating the payment transaction

Using GraphQL and Microservice #1, the frontend calls the relevant SAP DP endpoints to initiate the payment. In return, it receives two key elements: the transaction data and the DPJSLIB URL.

3. Injecting DPJSLIB

The frontend injects the DPJSLIB script into its codebase.

4. Loading available payment methods

Dedicated functions from DPJSLIB are then used to load all the available payment methods configured in SAP DP.

5. Presenting payment options to the customer

The payment methods are displayed directly in the customer’s browser.

6. Payment selection

The customer chooses their preferred payment method.

7. Order confirmation

Once the customer confirms the order, the frontend executes a dedicated DPJSLIB function that opens a payment window served by the PSP.

8. Draft order

At the same time, the system proactively submits a draft order to Microservice #2 via GraphQL and SAP Commerce. This order is not yet finalized — it is waiting for payment confirmation. Meanwhile, SAP Commerce triggers the payment finalization thread in Microservice #1.

9. User completes actions in PSP window

After the customer finishes all actions in the PSP payment window, a JavaScript promise is sent back to the frontend.

⚠️ Important: This promise only confirms that the user’s interaction has ended — it does not guarantee a successful payment. Final confirmation still has to come from SAP DP via dedicated endpoints. If the transaction fails early, the JS promise will return an error status, enabling the system to notify the customer immediately.

10. Backend finalization thread

At this point, the payment finalization thread in Microservice #1 checks the transaction status directly through SAP DP.

• If successful → the final order is placed in SAP ERP (via SAP Commerce and Microservice #2).
• If the status is “in progress” → the system retries the request until a final outcome is received.
• If unsuccessful → the system triggers customer alerts and notifications.

11. Frontend status checks

In parallel, the frontend also begins checking the final payment status via GraphQL and Microservice #1. Depending on the status retrieved, the system responds accordingly:

• Displays a success page if the payment is confirmed.
• Shows an error page or triggers another status check if the result is still pending, often accompanied by a loading animation to keep the customer informed.

Potential Pitfalls in the Payment Page Model

Even with careful planning, several challenges can occur:

Browser or Network Failures

The JavaScript promise may fail if the customer’s browser crashes, if there’s an internet outage, or if a frontend bug occurs. To prevent lost orders, we developed logic to proactively submit draft orders.

Without this safeguard, payments could be processed without triggering an order submission — creating risks for both the business and the customer. A better long-term solution would be for SAP DP to provide a callback mechanism to notify the system about completed payments.

Payment Method Filtering

Currently, available payment methods are loaded only on the frontend via DPJSLIB. For complex B2B scenarios, it is often necessary to filter payment options per customer or region.

A more scalable solution would be for SAP DP to offer a REST endpoint that returns all available methods. The integrated system could then apply filtering logic at the backend level.

Payment Finalization

At present, the system must continuously poll SAP DP endpoints to confirm payment status. This can create unnecessary load. A more efficient solution would again be callback notifications, where SAP DP pushes the final status to the backend.

Other Important Considerations

• SAP DP is not plug-and-play – Each PSP requires dedicated integration and close collaboration.
• PSP software testing – Every PSP delivers its own software, which must be thoroughly tested to ensure functionality.
• Local regulations – Each country has unique rules that must be complied with.
• Transaction times vary – Performance depends on PSP software, network conditions, and integration specifics.

Integrating SAP DP Direct PSP with the E-commerce System

In this model, the frontend integrates directly with the PSP. There is no universal guideline because every PSP works differently. To decouple business logic, we implemented a dedicated middleware REST service (Microservice #1) between the e-commerce platform and PSP.

Figure 5. Direct PSP Solution Architecture

Step 1. Payment completed at the PSP

The payment process is executed entirely by the chosen PSP. The final payment status is usually communicated via dedicated PSP webhooks, which confirm whether the transaction was successful or not.

Step 2. Making SAP DP aware of the transaction

Since the payment bypasses SAP DP during the checkout, the system does not automatically know that the transaction has taken place. To solve this, SAP provides dedicated endpoints that can be used to register (or “pair”) the PSP transaction with SAP DP.

Step 3. Middleware handles the pairing

In our customer’s solution, this step is handled by a dedicated Microservice #3. It listens for the PSP’s webhook notifications, collects the necessary payment details, and calls the SAP DP endpoints to create a corresponding transaction record inside SAP DP.

Step 4. Transaction created in SAP DP

Once paired, SAP DP creates a new internal transaction object representing the payment. At this stage, SAP DP enriches the record with its own identifiers such as tokens, authorization numbers, and other metadata needed for further financial processing.

Step 5. Pushing data to SAP ERP

After the transaction has been successfully created in SAP DP, all payment details are forwarded to SAP ERP, along with the corresponding order data. This flow is orchestrated by the e-commerce platform in combination with Microservice #2.

Step 6. Enabling financial operations in ERP

With both order and payment data now present in SAP ERP, the SAP DP module ensures smooth post-payment management. This includes activities such as reconciliation, accounting entries, or initiating refunds if necessary.

Figure 6. Direct PSP Sequence Flow

(Hover over the diagram to zoom into specific areas. A high-resolution version is also available for download in PDF and PNG formats.)

Our Findings About Direct PSP

• Every new PSP requires new development work.
• However, you gain a more personalized UX/UI compared to the Payment Page integration model, and you can use all PSP features because you are not limited by any intermediary interfaces.
• Clearer responsibility: the PSP owns the entire payment journey, reducing ambiguity in case of defects.

Conclusion

Our client’s project proved that both models have their place.

• Payment Page → faster rollouts, easier PSP switching, less complexity for commerce teams.
• Direct PSP Connection → maximum control, richer PSP-specific features, but higher development effort.

In either case, SAP Digital Payments remains the backbone, ensuring that all payment data flows securely into SAP ERP. This enables consistent accounting, refunds, and compliance — no matter how many PSPs are involved.

You might also like:

• SAP Digital Payments: Enabling Secure, Scalable, and Future-Ready Payment Processes » Learn more
• Post-Accelerator Frontend Strategies for New SAP Commerce Storefront » Learn more
• 7 key benefits of data sharing in e-commerce » Learn more
• Technology hacks for cost savings in e-commerce » Learn more
• Search in B2B e-commerce can be a strategic differentiator » Learn more