After the payment order or payment document is created, using event 6207, you can communicate directly with external financial institutions, such as banks, credit card companies, or virtual added networks. For this purpose, the data for the payment is made available, similarly to the logic of the payment run, in the format of the payment tables (DPAYH, DPAYP), but it is not stored in these tables.

In the format stored for the payment method, you can then create and send an XML message. If you use bank-specific formats, you can set a bank-specific format dependent on the data of the interface of event 6207. That means that you don't have to create a separate payment method for each bank.

If it is possible to send this message synchronously, the system can immediately process the synchronous answer.

If the bank confirms the payment, the system first determines if only a payment order was created, or if a payment document was created immediately. If the payment document was already created, then the system updates only the status of the external payment. If a payment order was posted, the system automatically captures the payment in a payment order lot, which you then post. In the Customizing activity Make General Settings, you can enter a prefix in the Prefix for Payment Order Lot field (see Customizing for Contract Accounts Receivable and Payable under  Payments Processing Incoming and Outgoing Payments Real-Time Payments ). The key for this payment order lot consists of the two-character prefix and the number of the payment order.

However, if the bank responds that the payment cannot be executed, the system either reverses the payment order only or creates and posts a returns lot for the payment. Which of these two takes place is determined by how the Returns Posting for Payment Order indicator is set in the Make General Settings Customizing activity. You can also define a prefix for this in Customizing. The system determines the return reason in event 6207.

If you do not set the indicator, the system reverses only the payment order. This also means that no returns activities are performed, and no bank fees are posted. The return reason (from event 6207) is noted in the payment order. To trigger follow-on activities such as creating correspondence, setting locks, or changing payment methods, use event 0695.

The indicator has no effect if instead of creating a payment order, a payment document was posted immediately. In that case, the system always creates and posts a returns lot when a payment is rejected. If a statistical down payment request was created in the case of an overpayment, the statistical down payment request is also reversed.

Both payment order lots and returns lots always contain just one individual payment or one individual return.

If the response of the bank (in event 6207) is not synchronous, the system can accept the response at a later time by calling the appropriate service separately. In that case, the execution of the steps (confirmation of the payment or rejection of the payment and naming of return reasons) corresponds largely to the description above. The data of this service is stored and processed in table DFKKEXC_ADD. If lock problems arise during processing of this asynchronous bank response, from the SAP Easy Access screen, choose  Payments Real-Time Payments and in the monitor choose  Repeat (Post Real-Time Payment Again).

In some cases, it's common for the bank, if payment is made using a virtual account, to immediately initiate a reversal of the payment after a certain waiting period without a response (for instance, 30 seconds). There is a separate service for reversing the payment in these cases. This data is also stored and processed in table DFKKEXC_ADD.