Server to Server
Overview
The payment gateway provides merchants with more structured types of solutions where sensitive transaction data (card data) are managed directly by your servers.
Server to Server (S2S) solutions allow a complete customization of the payment experience, but are subject to obtaining PCI DSS security certification (SAQ D questionnaire).
In the test area it is possible to try Server to Server solutions even if you do not have PCI DSS certification, but to make payments in production it is mandatory to provide Nexi with the SAQ D questionnaire, which must be verified before enabling the operator's terminal to operate.
For more information about certification, please refer to the official PCI Security Standards Council website.
This type of integration is dedicated to payment cards, it is not possible to integrate alternative payment methods following the specifications in this section. To proceed to implement other methods on a checkout page, it is recommended to create special buttons, implementing the specifications of the Hosted Payment Page solution using the "selectedcard" parameter to redirect the customer to the desired payment method. In this way you use the server to server solution for card payment, and the Hosted Payment Page solution for other methods such as PayPal, Apple Pay, Google Pay, etc...
Below are the types of S2S payment made available by Nexi:
- 2-Step Payment: payment by card subjected to 3D Secure authentication, the payment is divided into two calls.
- 3-Step payment: payment by card undergoing 3D Secure authentication, the payment is divided into three calls.
- M.O.T.O.: intended for those who want to integrate on their system the function of requesting authorization of payments by card, whose data have been communicated by the cardholder to the merchant via email, telephone, etc ... Not 3D Secure authenticated.
2 Steps and 3 Steps payments are subjected to 3D Secure authentication, the customer must be redirected to a specific address returned by XPay, which takes him to the authorization system of the card issuer, where he can proceed with the authentication for confirm the payment.
2-Step Payment
This solution allows you to make payments by card with 3D Secure authentication, in Server to Server mode. As the name of the solution suggests, payment is divided into two phases:
- 3D Secure registration and authentication verification: in the first phase it is necessary to verify, through the POST / orders / 2steps / init API, if the card entered by the customer is registered to the authentication protocol, the address and parameters necessary to perform 3D Secure authentication through a POST request with the format of a submission: form are then returned.
Example Form Construction
<form name="redirect" action="<%=threeDSAuthUrl%>" method="POST"> <input type=hidden name="ThreeDsRequest" value="<%=ThreeDsRequest%>" /> <input type=hidden name="ReturnUrl" value="<%=ReturnUrl%>" /> <input type=hidden name="transactionId" value="<%=operationId%>" />
| Name | Description | Format | |
|---|---|---|---|
| ✅ | threeDSAuthUrl | The address returned in response to the POST /orders/2steps/init. The URL of the card issuer to authenticate to. | |
| ✅ | ThreeDsRequest Property | The code returned in response to the POST /orders/2steps/init, to be sent to the authentication system. | AN |
| ✅ | ReturnUrl Property | The return URL to which the customer will be redirected and the result returned at the end of authentication. | |
| ✅ | transactionId | Identification of the operation. |
- Payment: in the second phase, if successful in 3D Secure authentication, authentication and payment are carried out via the POST API call
/orders/2steps/payment.
3-Step Payment
This solution allows you to make payments by card with 3D Secure authentication, in Server to Server mode. As the name of the solution suggests, payment is divided into three phases:
- 3D Secure registration verification: in the first step it is necessary to verify, through the /orders/3steps/init API, if the card entered by the customer is registered to the authentication protocol, the address and parameters necessary to perform 3D Secure authentication through a POST request with the format of a form submission are returned:
Example Form Construction
<form name="redirect" action="<%=threeDSAuthUrl%>" method="POST"> <input type=hidden name="ThreeDsRequest" value="<%=ThreeDsRequest%>" /> <input type=hidden name="ReturnUrl" value="<%=ReturnUrl%>" /> <input type=hidden name="transactionId" value="<%=operationId%>" />
| Name | Description | Format | |
|---|---|---|---|
| ✅ | threeDSAuthUrl | The address returned in response to the POST /orders/3steps/init. The URL of the card issuer to authenticate to. | |
| ✅ | ThreeDsRequest Property | The code returned in response to the POST /orders/3steps/inint, to be sent to the authentication system. | AN |
| ✅ | ReturnUrl Property | The return URL to which the customer will be redirected and the result returned at the end of authentication. | |
| ✅ | transactionId | Identification of the operation. |
M.O.T.O.
The M.O.T.O. (Mail Order Telephone Order) payment method refers to payments made in Server to Server mode, in which the 3D Secure authentication of the holder is not required. It is intended for those who want to integrate on their system the function of requesting authorization of payments by credit card, whose data have been communicated by the cardholder to the merchant via email, telephone, etc. This solution is not subject to 3D Secure authentication.
To integrate this solution, you must implement the POST /orders/moto.
Payment Flow
- The customer provides the card data to you (1).
- Your server initiates the payment via the POST/orders/moto API call (2).
- The gateway sends the payment request to the card issuer's authorization system (3).
- The authorization system returns the authorization result to the gateway (4).
- The payment gateway returns the outcome of the transaction to your server (5).
- You communicate the outcome of the transaction to the customer (6).