The PPRO Payment Gateway supports many payment methods that are different in the exact mode of operation. Thus the transaction can be carried out synchronously or asynchronously. This section describes what a standard workflow looks like.

The diagram below shows a workflow example for an asynchronous, web-based Payment Method.

1. You request a new transaction by sending the TRANSACTION call to the system.
2. The Payment Gateway validates the request and determines which payment method to use based on the following parameters:
   currency
countrycode
channel
tag
specin (payment method-specific input data)
3. The Payment Gateway responds synchronously with the current STATUS of the transaction. The status determines the next step:
   SUCCEEDED: The request succeeded immediately. This state is considered final.
   FAILED: The request failed. The merchant must inform the consumer. Depending on the payment scheme, a transaction can switch from FAILED to SUCCEEDED state later, for example, if funds arrived nonetheless or later than expected.
   PENDING: In combination with a REDIRECTURL in the response, you must redirect the consumer to a specified URL.

👍

Note

Some payment methods use PENDING without a redirect URL. See Payment methods without redirection.

4. If the response status is PENDING, you must redirect the consumer to the URL specified in the response.
5. The consumer makes the payment, for example, on their bank's website.
6. The consumer is redirected to the merchant via the merchantredirecturl specified in the TRANSACTION request.
7. You verify the parameters passed when redirecting and send the GETTXSTATUS call to check the transaction outcome. If the outcome is still PENDING, recheck the status several times and inform the consumer that the transaction is delayed. For some payment methods, this is the default behaviour.
   As an alternative, the GETTXSTATUSBYMERCHANTTXID call can be used.
8. As soon as an asynchronous transaction enters one of the states:
   SUCCEEDED
   FAILED
   The Payment Gateway emits a notification to the specified notificationurl. In turn, verify the notification and request the transaction status using the GETTXSTATUS call (or, as an alternative, the GETTXSTATUSBYMERCHANTTXID call).

Payment methods without redirection

There are payment methods that do not use redirection because the payment process doesn’t need any consumer interaction. In this case, a SUCCEEDED, FAILED or PENDING status is returned in response to the initial transaction request. You can find more information about this behaviour in the specific payment method entries. These payment methods often return the output parameter SPECOUT.REDIRECTOPTIONAL.

If the transaction is processed asynchronously, there will be a PENDING status without a redirect URL. A notification (see Notifications) informs you if the result of the transaction becomes available.

In this scenario, the payment flow only includes a transaction request, and you are notified. In-store payment methods may require polling the status apart from only waiting for a notification, to complete the payment quickly while the consumer is waiting in the store. You can find more information about this requirement in the specific payment method entry.

👍

Note

If the payment method follows a different process model, the specific payment method documentation includes these details. We recommend that your implementation also supports transaction processes without redirection.