Customer receipts automation through payment servi...

sivamothukuri84 · ‎03-29-2023

This document explains how to create an inbound interface between payment service providers and SAP. The solution focuses on the automation of customer payment transactions made via various payment methods on the client's e-commerce website.

This solution would be cost-effective and appropriate for customers who run their businesses in SAP ECC.

Business case:

Key Drivers for the automation of the process: -

When processing the transaction into SAP, the client followed a manual process that was prone to errors.

The Finance Business user logs into the payment provider website (PayPal, WorldPay, Amex & Klarna) and downloads a file containing payment transactions from a particular date, converts the file into a WinShuttle format, and then loads those transactions into SAP. A file downloaded today would contain sales from yesterday, since the user tends to check for and process the files on Mondays and Fridays, but with additional sensitivity around month-ends.

Before uploading the files into SAP, the user must follow certain steps to manipulate the files downloaded from the payment provider's portal.

The unloadable file should include a few standard transaction codes of the payment providers.

Manual processing and file manipulation would depend on the solution designed to process the uploaded file.

Payment transactions will be posted by the process file, calling SAP transaction code F-28, debiting the bank GL account and crediting the customer account. This process is not the same for all other payment providers. The receipt amount is net of the fee paid to the payment service providers.

Additional transactions such as refunds, chargebacks, chargeback fees, etc, will also be captured and posted into finance along with receipt postings.

Key Rationale:

Reduce manual effort and remove risk of human error: The incoming transaction records are processed, manipulated and transformed into a loadable format with minimal human effort.

Provide future-proofing in the event that sales transaction volumes increase.

Provide a daily stock reconciliation process similar to the one already in place for the various integrated 3PLs.

Improve stock and payment reconciliation (removing write-offs where data cannot currently be reconciled) by aligning BRUSA with Business Intelligence processes, especially in capturing data at the order level (rather than at the summary level).

Components of Integration –

In order to automate and integrate the Payment service providers with SAP, the development of SAG, PI, and SAP ECC is proposed.

SAP PI can be integrated with the payment service provider's portal to retrieve transaction files from their SFTP folders. Based on the country in which the transactions were originated, the PSP will make the files available at pre-defined intervals and they will be transmitted to SAP AL11 folders for creation of Idocs.

PI (Process Integration) integrates with SAP to process transaction files automatically.

Through context types and mapping of source values to target values, the value mapping table can be used to derive certain important target parameters into the inbound interface. When mapping a transaction file to an Idoc, SAP PI will perform a lookup.

Duplicate check functionality to prevent processing of transaction files more than once. In order to store all processed files, a bespoke table was created, and before processing any file, PI checks the bespoke table to see if any other files with the same name exist. If PI identifies a duplicate file, the file will not produce an IDOC.

PI -

Sender File Adapter with Content Conversion to maintain node names and field names as per the Payment Transaction file.

Create Structure of the file in Enterprise Service Repository with field names based on the File Content Conversion Parameter defined in Integration Builder.

Create Mapping transformation (Node & Field level mapping logics) from Payment Transaction file to IDOC structure in Enterprise Service Repository.

Create Integrated Configuration with IDOC Receiver Adapter.

Value Mapping –

In Payment providers integration, the value mapping functionality plays a pivotal role in converting a parameter from a source format to target value format to populate the parameters into the FI Idocs.

Context types are created to group the source information on the origin of the data

In the current model, the value mapping replication happens from source system to the target PI (Process integration) system.

File Formats -

The payment transaction file from each payment service providers will be distinct.

A complex data mapping should be designed, to read, transform and translate the source file format into a target application document (SAP Idoc & SAP document).

Each field and column of the payment transaction files provided by the payment providers should be read by the data mapping design.

Payment files supplied by payment providers could be in any format, for example, CSV or TXT.

PSP file formats are very distinct, so it is preferred to have separate PI mapping logic for each file format from the PSPs (ex. PayPal, Worldpay, Amex, Klarna).

Each field in the transaction file should be translated and populated, into the fields of the Idoc segments.

Because the fields are interpreted differently by each payment provider, the data mapping will be complex.

A “unique transaction type or event type code” identifies each transaction in the file, which is different for each payment provider.

PSP portals and SFTPs create different file formats, and payment providers are very reluctant to modify the formats.

Despite the apparent simplicity of the overall solution design, mapping the fields and realizing the business need will be extremely challenging.

Business Impact: -

Through the integration of payment service providers, the customer receipts process will be automated, reducing the manual effort in clearing receipts items during month-end closing by matching the same reference field from the O2C sales order automation.

The financial impact on recording the receipts, tax and fees is unique to the payment service providers.

Users can reconcile the total receipts posted through automation with those in the file downloaded from the portal.

When a PSP sends a file with new transactions, it may include a new event code that has never been mapped to a business rule in PI. To identify and post correction journals by the business, we have designed a solution to post to the same bank GL account with unique line-item text.

S/4 Hana Road map (SAP Digital payments Add-on solution): -

The SAP digital payments add-on integration offers an out-of-the-box alternative to current custom payment service provider (PSP) integrations. This integration makes use of SAP's digital payments add-on with ready-to-use PSP connectivity.

Summary: -

By establishing an inbound interface between payment service providers and SAP, customer payment transactions can be automated in a simple manner, especially for customers who run their businesses in SAP ECC.