This guide walks you through the entire payment journey, from start to finish. As a merchant, you’ll be in full control,
collecting all card and payment details directly. This behind-the-scenes process ensures a smooth and seamless experience for
your shoppers. Navigate the complexities of the payment landscape with ease and efficiency, all thanks to our Server-to-Server
guide. Start your journey today!
PCI-DSS Compliance: To collect card data, you must be PCI-DSS compliant. To minimize your compliance requirements, please use Primeiro Pay. HTTP POST Requests: Remember, for an HTTP POST request, all parameters must be incorporated in the message body, not in the URL. API Reference: Consult the API Reference for a detailed list of parameters that can be included in the payment request.
Initiate a server-to-server POST request with the required payment data. The payment details are verified with the issuer,
and the funds are reserved. The response to a successful request is an id that should be stored and used in
subsequent back-office operations.
2. Capture the payment
Initiate a server-to-server POST request over the pre-authorized payment. The reserved funds are transferred from the
shopper's account to the merchant's account.
Sample request:
3. Manage the payment
Initiate a back-office server-to-server POST request over the captured payment to:
refund either the full captured amount or a part of the captured amount (see refund)
rebill the processed order for additional products (see rebill)
reflect the chargeback processed by the bank (see chargeback)
reflect the chargeback reversal processed by the bank (see chargeback)
Initiate a server-to-server POST request with the required payment data. The payment details are verified with the issuer,
and the funds are captured. The response to a successful request is an id that should be stored and used in
subsequent back-office operations.
2. Manage the payment
Initiate a back-office server-to-server POST request over the debit payment to:
refund either the full captured amount or a part of the captured amount (see refund)
rebill the processed order for additional products (see rebill)
reflect the chargeback processed by the bank (see chargeback)
reflect the chargeback reversal processed by the bank (see chargeback)
Operation:
Reason:
Sample request:
Asynchronous payment
The merchant collects card data from the shopper and initiates the asynchronous payment flow.
How it works
Pre-authorization + Capture
Debit
Pre-authorization + Receipt
Select your transaction flow. Be aware, some payment brands may not support your chosen flow. Check for compatibility.
Initiate a server-to-server POST request with the required payment data and the shopperResultUrl that must
be url-encoded. The payment details are verified with the issuer, and the funds are reserved. The response to a successful
request is an id that should be stored and used in subsequent back-office operations.
2. Redirect shopper
Initiate a server-to-server request to guide the account holder through the validation and completion of the payment.
Follow these steps to facilitate the redirection:
Interpret the JSON Redirect
Extract the redirect information from the response of the initial authorization payment.
Parameter
Description
url
The HTTPS URL for redirection, used as the form’s action attribute.
method
The form submission method, defaults to HTTPS POST.
parameters
Appended to the URL for HTTPS GET, or included in the body for HTTPS POST. For HTTPS POST, each parameter
will be a hidden input field in the HTML form.
Use Redirect Response Parameters
Utilize these parameters with an HTML form to perform the shopper's redirect.
3. Get the payment status
Once the payment request is processed, the customer is redirected to your shopperResultUrl along with a GET parameter resourcePath.
resourcePath=/v1/payments/{id}
Sample request:
You’re allowed two payment status requests per minute per transaction. However, the query endpoint provides payment status without such restrictions.
4. Capture the payment
Initiate a server-to-server POST request over the pre-authorized payment. The reserved funds are transferred from the
shopper's account to the merchant's account.
Sample request:
5. Manage the payment
Initiate a back-office server-to-server POST request over the captured payment to:
refund either the full captured amount or a part of the captured amount (see refund)
rebill the processed order for additional products (see rebill)
reflect the chargeback processed by the bank (see chargeback)
reflect the chargeback reversal processed by the bank (see chargeback)
Initiate a server-to-server POST request with the required payment data and the shopperResultUrl that must
be url-encoded. The payment details are verified with the issuer, and the funds are captured. The response to a successful
request is an id that should be stored and used in subsequent back-office operations.
2. Redirect shopper
Initiate a server-to-server request to guide the account holder through the validation and completion of the payment.
Follow these steps to facilitate the redirection:
Interpret the JSON Redirect
Extract the redirect information from the response of the initial authorization payment.
Parameter
Description
url
The HTTPS URL for redirection, used as the form’s action attribute.
method
The form submission method, defaults to HTTPS POST.
parameters
Appended to the URL for HTTPS GET, or included in the body for HTTPS POST. For HTTPS POST, each parameter
will be a hidden input field in the HTML form.
Use Redirect Response Parameters
Utilize these parameters with an HTML form to perform the shopper's redirect.
3. Get the payment status
Once the payment request is processed, the customer is redirected to your shopperResultUrl along with a GET parameter resourcePath.
resourcePath=/v1/payments/{id}
Sample request:
You’re allowed two payment status requests per minute per transaction. However, the query endpoint provides payment status without such restrictions.
4. Manage the payment
Initiate a back-office server-to-server POST request over the captured payment to:
refund either the full captured amount or a part of the captured amount (see refund)
rebill the processed order for additional products (see rebill)
reflect the chargeback processed by the bank (see chargeback)
reflect the chargeback reversal processed by the bank (see chargeback)
Initiate a server-to-server POST request with the required payment data and the shopperResultUrl that must
be url-encoded. The payment details are verified with the issuer, and the funds are reserved. The response to a successful
request is an id that should be stored and used in subsequent back-office operations.
2. Redirect shopper
Initiate a server-to-server request to guide the account holder through the validation and completion of the payment.
Follow these steps to facilitate the redirection:
Interpret the JSON Redirect
Extract the redirect information from the response of the initial authorization payment.
Parameter
Description
url
The HTTPS URL for redirection, used as the form’s action attribute.
method
The form submission method, defaults to HTTPS POST.
parameters
Appended to the URL for HTTPS GET, or included in the body for HTTPS POST. For HTTPS POST, each parameter
will be a hidden input field in the HTML form.
Use Redirect Response Parameters
Utilize these parameters with an HTML form to perform the shopper's redirect.
3. Get the payment status
Once the payment request is processed, the customer is redirected to your shopperResultUrl along with a GET parameter resourcePath.
resourcePath=/v1/payments/{id}
Sample request:
You’re allowed two payment status requests per minute per transaction. However, the query endpoint provides payment status without such restrictions.
4. Handle the receipt
If you prefer to manage bank receipt confirmations yourself, initiate a server-to-server POST request for the pre-authorized payment. A receipt signifies the transfer of reserved funds from the shopper’s to
the merchant’s account. However, this step is optional as the system can automatically process the receipt upon receiving a notification from the bank, depending on the payment method.
Sample request:
5. Manage the payment
Initiate a back-office server-to-server POST request over the receipt (confirmed payment) to:
refund either the full captured amount or a part of the captured amount (see refund)
rebill the processed order for additional products (see rebill)
reflect the chargeback processed by the bank (see chargeback)
reflect the chargeback reversal processed by the bank (see chargeback)