This page will walk you through the basics for:

• What is Worldline Payment Gateway and how it works
• The transaction flow
• 3rd party platforms
• Supported Transaction Types

Worldline Payment Gateway

Worldline Payment Gateway provides a solution for businesses that wish to integrate with a mechanism for payments in their virtual stores (e-shops).
The platform supports all types of payments transactions in real time, provides convenience and flexibility in the way of interconnection to the virtual store, covering all necessary infrastructure for secure online payment processing.

The chart below describes the basics, using AlphaBank as an example:

• Customer has completed adding items to their cart, and proceeds with payment by navigating to the checkout page.
• From the checkout page a POST request is sent to VPOS, with enough data for Worldline to authenticate the merchant (MID, digest, etc).

**The Merchant’s system is only aware of the VPOS, communication between VPOS & MPI takes place internally.

• The customer gets redirected to the VPOS payment page, and inserts the card data.
• Payment page has a 30 mins timeout while the 3D page has only 15 minutes.
• On submission, a POST request is sent to VPOS, with all the parameters and their digest calculated by the merchant’s system.
• When the customer submits the card data, VPOS checks if the merchant is 3D Secure or not.
• In case merchant is 3D Secure, VPOS connects to MPI which performs the authentication:

MPI uses the card’s BIN to send a request to the corresponding Directory Server to:

• Determine if the card is enrolled to 3d
  Get the card Issuer’s ACS url
  The MPI sends a Request to ACS

• The ACS redirects to the 3D Secure Page. As soon as the customer passes the 3D challenge, ACS returns the control to MPI.
• MPI receives the response and sends it back to VPOS

3D secure data travel all the way, so that the bank can decline if no 3D authentication took place.

• VPOS proceeds with authorization by sending a request to PZAC in Bic Iso format.

• If the authorization is successful, then VPOS makes a POST request to the merchant’s confirmURL.
• If authentication or authorization fails then VPOS makes a POST request to the Merchant’s cancelURL.

HTTP POST Interface (Redirect)

The control flow for 3-D authentication using HTTP Post interface is the following:
1. Merchant payment page asks the user all the relevant payment data, such as card number, expiry, etc. and calculates digest (VPOS
v3.0 or earlier) or signature (v4.0) and POSTs these fields to the MPI.
2.
2. MPI checks the card participation from the 3-D Secure directory and returns the redirection page to the Card Issuer’s ACS (Access
Control Server). The right directory is found with either card scheme id or matching the beginning of the card number.
3. After the ACS is finished with the user authentication, ACS returns the control to the MPI. The MPI Server verifies the signature of
ACS and POSTs the response to either success URL or fail URL, which the MPI has earlier passed to the ACS.
4. Merchant payment page reads the response and continues with the authorization of the payment (or does the error processing).

XML Interface (Direct)

The control flow for 3-D authentication using XML interface is the following (ThreeDSecure 1.0):
1. Merchant payment page asks the user all the relevant payment data, such as card number, expiry, etc. and calculates digest (VPOS
v3.0 or earlier) or signature (v4.0) and POSTs the XML to MPI with Content-Type=application/xml.
Note that Merchant should set termUrl parameter in the request message. It should represent Merchant page url, where ACS will
post PARes (Payer Authentication Response) message after user authentication.
2. MPI checks the card participation from the 3-D Secure directory and if card is enrolled returns the ACS redirection page to Merchant.
3. Merchant redirects user browser using the redirection template. After the ACS is finished with the user
authentication, ACS returns the control to the Merchant. Merchant receives PARes and sends PAResValidationRequest to the MPI.
Message digest should also be included.
4. The MPI Server verifies the signature of PARes and responds to Merchant.
5. Based on returned parameters Merchant proceeds with transaction authorization or stops the transaction in case of error or
authentication failure.

MPI is responsible only for 3-D secure authentication

Only Alpha Bank supports acquiring for AMEX & Dinners cards for now