Describing External Digital Payments (2LZ)

The digital economy is putting pressure on finance departments around the globe.

This is the new normal of volatility - it is not just in the traditional areas of currency exchange risk and commodity prices, but also includes macroeconomic volatility and rapidly changing consumer preferences. In addition, tax policy volatility and complex regulatory requirements are challenging finance departments to provide ever deeper and ever more real-time information.

The second challenge is the proliferation of business model change, across all industries. Industry lines are blurring and the number of mergers and acquisitions continues to grow, becoming a standard model for achieving growth and innovation. Disruptive competitors are entering the market at an increasing pace. The emergence of digitally-enabled business models is forcing finance to become ever more agile and proactive.

As a result, finance is being asked to drive strategy in a whole new different way - providing real-time insight and proactive advice on investments, mergers and acquisitions, and on business model transformation.

In addition, finance is being asked to support the process of digital transformation across the enterprise. The sum of these changes has the potential to impact the entire financial value chain. Everything from how we bill, collect, report, and pay taxes, to how we plan for and control the business is going digital and real-time.

Enterprises have realized that finance transformation will help drive innovation and manage this volatility.

Real-time payments without external digital payments can be costly and tedious. The following constraints result from legacy system landscapes.

Payment service provider (PSP) integration:

• Customer-specific implementation and maintenance for each PSP
• Technical lock-in

Payment methods:

• Restricted to credit card payments
• Further digital payment methods only available via a custom implementation

Reconciliation

No automatic post processing in accounting, high manual effort and error-prone

The SAP digital payments add-on is a payment hub between PSP and SAP components, solutions, or applications that need to process incoming credit card or external payments.

The scope item enables the integration between SAP S/4HANA Cloud and the digital payments add-on. With this, you can use external payment methods in SAP S/4HANA for incoming payments.

The complete process is covered and automated, from payment advice processing via digital payments jobs, to automatic clearing and the final bank statement upload.

Various payment service providers are supported.

The activation of this scope item requires an additional license for the respective SAP Cloud Platform products Digital Payments and Customer payments.

You should consider these points when implementing the digital payments add-on and external digital payments:

• The customer needs to license the digital payments add-on (which is transaction-based).
• SAP S/4HANA Cloud, SAP S/4HANA On-Premise, and several other SAP solutions are integrated out-of-the-box.
• Integration with PSPs is available out-of-the-box. The customer must also have a contract with the PSP(s) of their choice.

The SAP digital payments add-on enables you to connect SAP and non-SAP consumer applications with non-SAP payment service providers (PSPs). Its function is to facilitate secure, end-to-end processing of digital payments.

You can connect to the payment service providers shown via the SAP digital payments add-on (providing you have a contract with the PSP in question).

Note: Digital payment functions delivered are depended on the services consumed and delivered within the consumer application, please verify the covered scenarios with SAP/SAP Help in advance.

Note

Systems highlighted with an asterisk must be integrated via APIs. The remaining system are out-of-the-box integrated.

SAP digital payments is a payment hub between payment service providers and SAP components, solutions, or applications that process incoming credit card payments.

The scope item enables the integration between SAP S/4HANA Cloud and SAP digital payments, which allows for the use of credit card payment methods in SAP S/4HANA for incoming payments.

The complete process from settlement using secure tokens via payment service provider advice to final bank statement is covered and automated. Various payment service providers are supported.

The SAP digital payments add-on also supports what are referred to as external payments. External payments are payments made using external channels, such as online or mobile payments systems, rather than payment cards. This part is facilitated by Best Practice Scope Item 2LZ. The external digital payments are especially geared towards payment solutions like PayPal.

Depending on the PSP's functional scope, external payments can be implemented using either a one-step procedure (known as direct capture), where the payment is charged directly to the payer's account without any prior authorization, or a two-step procedure (known as charge with authorization) where the payment is first authorized at the payer's account before being charged.

The system landscape for payment scenarios using the SAP digital payments add-on is composed of the following three elements:

• Consumer application: The communication between the consumer application, such as SAP S/4HANA Cloud, and the customer account in the SAP Cloud Platform works using REST Web services and is generally triggered by the consumer application.
• SAP digital payments add-on on SAP Cloud Platform: The SAP digital payments add-on processes the requests from the consumer application and routes them to the relevant external payment service provider (PSP). The add-on contains one core adapter and one adapter for each PSP.
• Payment Gateway: The SAP digital payments add-on and the external PSPs communicate using Web services. Most of this communication is synchronous.

The interaction between the system on a high level looks as follows:

1. The consumer application sends a request to the SAP digital payments add-on.
2. Based on the details of the request, the SAP digital payments add-on determines the relevant PSP in a process called routing.
3. The request is then forwarded to the relevant PSP via its adapter where it is mapped into the appropriate format.
4. Connection to PSP is established using the technical requirements of the PSP. Identification of the account at the PSP by the credentials provided by the PSP.

Several SAP S/4HANA Cloud consumer applications shown can be integrated with the External Digital Payments.

The consumer application sends a request to the External Digital Payments. Based on the details of the request, the External Digital Payments determines the relevant PSP in a process called routing. The request is then forwarded to the relevant PSP adapter where it is mapped into the appropriate format. Then the connection to the PSP is established using the credentials already maintained by the system administrator and the request is sent using the technical protocol required by the PSP.

In case of External Digital Payments, like if PayPal should be used, the consumer applications talk to the SAP digital payments add-on - External Digital Payment (2LZ) part. This scope item in turn can initiate several services using the SAP digital payments add-on. Those could be for example, external payment direct capture, external payment refund, or a digital payment advice.

Again all of the information generated via the External Digital Payments can be further processed in the SAP S/4HANA Cloud system when it comes to Cash Management or Accounts Receivables Management.

The complete process for the external digital payment scenario can be described as the following:

• A user orders a product and wants to pay using an external payment channel. Approval for the final transaction must be obtained from the PSP.
• The consumer application sends a request for direct capture to the SAP digital payments add-on. Based on the payment type, the relevant PSP is determined, and an initiation request is sent to the PSP in the appropriate format.
• The user approves the direct capture request on the user interface of the PSP, which is called by the consumer application.
• Once approval is obtained, the execution request for direct capture is sent. The result is returned to the consumer application via the SAP digital payments add-on.

• A user orders a product and wants to pay using an external payment channel. Approval for the amount of the transaction must be obtained from the PSP.
• The consumer application sends an authorization request to the SAP digital payments add-on. Based on the payment type, the relevant PSP is determined, and an initiation request is sent to the PSP in the appropriate format.
• The user approves the authorization request in the user interface of the PSP, which is called by the consumer application.
• Once approval is obtained, the execution request for authorization is sent. The result is returned to the consumer application via the SAP digital payments add-on.

• The consumer application triggers settlement runs periodically to settle authorized external payments.
• The authorization is sent to the SAP digital payments add-on to be settled.
• Based on the authorization, the relevant PSP is determined, and the request is sent to the PSP in the appropriate format.
• The PSP then processes the settlement and returns the result to the consumer application via the SAP digital payments add-on.

• The consumer application executes a report periodically to request advice details about the digital payments that have been processed.
• This request is sent to the SAP digital payments add-on.
• The add-on requests the advice details from all relevant PSPs.
• The advice details are merged and returned to the consumer application.

This is standard FI-AR functionality for important bank statement details. The bank statement is usually very aggregated and is therefore not useful for clearing (no settlements, no individual transactions). That is why the advice functionality is so helpful for Finance teams.

Sometimes, the granularity of the data is different - the advice might not have all the details, (coming later), or the advice might be not reflect the settlement granularity. The AR accountant could run automated clearing run (periodic job) to clear cash clearing accounts at a later point in time (also standard FI-AR functionality).

• The card acquirer transferred money to our account at our bank.
• The bank statement is imported through standard process (no change in the Digital Payments scenario).
• It will then show you that the payment has been received: you will see the incoming payment amount which corresponds to the total net amount of the clearing house statement.

1. A user orders a product and wants to pay using an external payment channel. Approval for the final transaction must be obtained from the PSP.
2. The consumer application sends a request for direct capture to the SAP digital payments add-on. Based on the payment type, the relevant PSP is determined, and an initiation request is sent to the PSP in the appropriate format.
3. The user approves the direct capture request on the user interface of the PSP, which is called by the consumer application.
4. Once approval is obtained, the execution request for direct capture is sent. The result is returned to the consumer application via the SAP digital payments add-on.

1. A user orders a product and wants to pay using an external payment channel. Approval for the amount of the transaction must be obtained from the PSP.
2. The consumer application sends an authorization request to the SAP digital payments add-on. Based on the payment type, the relevant PSP is determined, and an initiation request is sent to the PSP in the appropriate format.
3. The user approves the authorization request in the user interface of the PSP, which is called by the consumer application.
4. Once approval is obtained the execution request for authorization is sent. The result is returned to the consumer application via the SAP digital payments add-on.

1. A user cancels an order for which an external payment has already been approved.
2. The consumer application sends an authorization cancellation request to the SAP digital payments add-on.
3. Based on the type of the payment, the relevant PSP is determined and the request is sent to the PSP in the appropriate format.
4. The PSP processes the cancellation and returns the result to the consumer application via the SAP digital payments add-on.
5. If cancellation is not possible, the consumer application is informed.

1. The consumer application triggers settlement runs periodically to settle authorized external payments.
2. The authorization is sent to the SAP digital payments add-on to be settled.
3. Based on the authorization, the relevant PSP is determined, and the request is sent to the PSP in the appropriate format.
4. The PSP processes the settlement and returns the result to the consumer application via the SAP digital payments add-on.

1. The consumer application requests a refund when an external payment that has already been settled has to be paid back to the customer, for example in the case of a return.

   The request contains reference information about the payment to be refunded.

2. The PSP processes the refund and returns the result to the consumer application via the SAP digital payments add-on.

1. The consumer application executes a report periodically to request advice details about the digital payments that have been processed.
2. This request is sent to the SAP digital payments add-on.
3. The add-on requests the advice details from all relevant PSPs.
4. The advice details are merged and returned to the consumer application.

The following sections show how the procedure to authorize external digital payments is handled in Finance.

As a first step payments are transferred to Financials accounts receivables by different channels, for example:

• Customer portal
• Online shop
• Point of sale via sales/distribution

These payments are represented as open items in account receivables external payment clearing accounts (G/L accounts). The corresponding item on the customer account is automatically cleared against this.

In order to settle external digital payments you can use the app Schedule Accounts Receivable Jobs. Pick the standard credit card settlement option from the list and set your parameters for the scheduling or selections for company code and G/L account.

This settlement report creates batches and sends them to the payment service provider (via the SAP digital payments add-on). Thereby items on the AR credit card clearing account will cleared and posted to a cash clearing account for credit cards.

Data provided in the digital payment advice is used for the automatic reconciliation in Financials.

Note

Advice processing is not supported by all PSPs. For more information, see the SAP Help Portal.

Advice information is requested using the digital payments advice report from Schedule Accounts Receivables Jobs in SAP S/4HANA Cloud. When the report is executed, the digital payments add-on request the advice from the PSP. The data is processed into Accounts Receivables.

Items on the cash external payment clearing account will cleared and posted to a cash external payment transfer account (considering charges). The cash external payment clearing account is cleared automatically by a periodic G/L automatic clearing report.

The transfer of the collected money to a bank account is triggered by the standard bank statement functionality. When importing external bank statements, the corresponding bank statement items are posted against the cash external payment transfer account.

The clearing of the cash external payment transfer account is typically done manually, depending on the reference information.