Server-to-Server

Server-to-Server

Embark on a journey with our all-encompassing Server-to-Server guide, your ultimate companion for accepting and managing payments. 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 COPYandPAY.
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.

Use cases

Synchronous payment

The merchant collects card data from the shopper and initiates the synchronous payment flow.


How it works

Pre-authorize payment

Send the pre-authorization request with the collected card data.

Capture the payment

Send the capture request.

OPTIONAL

Manage the payment

Send the back-office payment request.

Transactions:
PA
PA
CP
CP
RF
RF
CB
CB
CR
CR
RB
RB

1. Pre-authorize payment

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 server-to-server POST request over the captured payment to:

Operation:

Sample request:

Perform debit payment

Send the debit request with the collected card data.

OPTIONAL

Manage the payment

Send the back-office payment request.

Transactions:
DB
DB
RF
RF
CB
CB
CR
CR
RB
RB

1. Perform debit payment

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 server-to-server POST request over the debit payment to:

Operation:

Sample request:

Asynchronous payment

The merchant collects card data from the shopper and initiates the asynchronous payment flow.


How it works

Pre-authorize payment

Send the pre-authorization request with the collected card data.

Redirect shopper

Redirect the shopper to validate and complete the payment.

Get the payment status

Find out if the payment was successful.

Capture the payment

Send the capture request.

Transactions:
PA
PA
CP
CP
OPTIONAL

Manage the payment

Send the back-office payment request.

Transactions:
RF
RF
CB
CB
CR
CR
RB
RB

1. Pre-authorize payment

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. To facilitate this redirection, you need to interpret the redirect object from the response of the pre-authorized payment. This redirect object, along with its parameters, will be used in conjunction with an HTML form to perform the shopper’s redirect.

  • url: The HTTPS URL for redirection, used as the form’s action attribute.
  • method: Defaults to HTTPS POST, determines form submission method.
  • parameters: Appended to URL for HTTPS GET, or included in the body for HTTPS POST. In the case of an HTTPS POST, each parameter will be a hidden input field in the HTML form.

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 reversal allows you to cancel the The reserved funds are transferred from the shopper to merchant's account.

Sample request:

5. Manage the payment

Initiate a server-to-server POST request over the captured payment to:

Operation:

Sample request:

Perform debit payment

Send the debit request with the collected card data.

Redirect shopper

Redirect the shopper to validate and complete the payment.

Get the payment status

Find out if the payment was successful.

OPTIONAL

Manage the payment

Send the back-office payment request.

Transactions:
DB
DB
RF
RF
CB
CB
CR
CR
RB
RB

1. Perform debit payment

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. To facilitate this redirection, you need to interpret the redirect object from the response of the pre-authorized payment. This redirect object, along with its parameters, will be used in conjunction with an HTML form to perform the shopper’s redirect.

  • url: The HTTPS URL for redirection, used as the form’s action attribute.
  • method: Defaults to HTTPS POST, determines form submission method.
  • parameters: Appended to URL for HTTPS GET, or included in the body for HTTPS POST. In the case of an HTTPS POST, each parameter will be a hidden input field in the HTML form.

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 server-to-server POST request over the captured payment to:

Operation:

Sample request:

Payment cancellation

The merchant cancels the entire open amount of a pre-authorization. Depending on the payment method, the pre-authorization expire usually after a couple of days unless it is already captured or cancelled.


How it works

Pre-authorize payment

Send the pre-authorization request with the collected card data.

Reverse the payment

Send the reversal request to cancel the pre-authorization.

Transactions:
PA
PA
RV
RV

1. Pre-authorize payment

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 reversing the pre-authorization.


2. Reverse the payment

Initiate a server-to-server POST request over the pre-authorized payment. The payment is cancelled when you have authorized a payment but do not want to capture it, for example because an item is out of stock. The reserved funds are released to the shopper's account.

Sample request:

Chargeback

The merchant reflects the chargeback and its reason as received from the bank to indicate a reversal of funds from the merchant's account into the shopper's account. This typically happens when a shopper disputes a debit or credit card charge with their bank, leading to a reimbursement, rather than dealing directly with the business that made the charge.

Originally, chargebacks were designed as a form of consumer protection against credit card fraud. However, they can also be initiated due to billing errors, unresolved customer complaints, or unrecognized charges.

As a business, it’s crucial to minimize chargebacks. Understanding how to prevent them and how to work with your payment processing company to dispute them is key.

How it works

Perform debit payment

Send the debit request with the collected card data.

Perform the chargeback

Send the chargeback request with the reason of the dispute.

OPTIONAL

Perform the chargeback reversal

Send the chargeback reversal request upon dispute won by the merchant.

Transactions:
DB
DB
CB
CB
CR
CR

1. Perform debit payment

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 chargeback to reflect the reversing of the funds.


2. Perform the chargeback

Initiate a server-to-server POST request using the post-payment authorization id. A chargeback signifies the reversal of funds back to the shopper’s account following a dispute. When a shopper initiates a chargeback, the merchant is entitled to contest the legitimacy of the original transaction. The merchant can do this by collecting and presenting persuasive evidence (such as receipts, delivery confirmations, etc.) that contradicts the shopper’s claim. This procedure of challenging a chargeback is referred to as representment.

Reason:

Sample request:

3. Perform the chargeback reversal

Initiate a server-to-server POST request using the chargeback payment id to perform a chargeback reversal. This reversal takes place subsequent to the representment process. If the issuing bank rules in favor of the merchant after reviewing the provided evidence, the chargeback is then reversed. Consequently, the funds initially debited from the merchant and credited to the shopper due to the chargeback are retracted from the shopper and reinstated to the merchant. Notably, even in the event of a chargeback reversal, the merchant remains liable for the chargeback fee, and the transaction continues to contribute to the merchant’s chargeback ratio.

In summary, representment is the procedure of contesting a chargeback, and a chargeback reversal is a potential result of this dispute.

Sample request:

Payout

The merchant uses standalone credit transactions, also known as a standalone refunds, to transfer funds from their account back to the shopper’s account without a corresponding debit transaction. This could occur in several scenarios:

  • Expired Refund Window: When the standard timeframe for refunds, usually 60 days, has passed but you still need to return funds to the shopper. For example, if a shopper returns a product after 70 days, you would initiate a standalone credit transaction.
  • Billing Error Correction: When a billing error has occurred and you need to correct it. For example, if a shopper was accidentally billed twice for a single item, you would issue a standalone credit for the amount of the duplicate charge.
  • Customer Service Gesture: When you want to provide a credit as a gesture of good customer service. For example, if a shopper had a poor experience, you might issue a credit as an apology and a way to maintain a positive relationship.
Unlike regular refunds, a standalone credit has no relationship to any original capture of funds. To issue a refund via standalone credit, the merchant must obtain the cardholder’s card and bill-to information. This ensures fairness in transactions and maintains shopper satisfaction.

To know which acquirers or payment methods do support payment credit, please reach out to your Customer Success Manager.

How it works

Payout shopper

Send the credit request with the collected card and bill-to data.

Transactions:
CD
CD

1. Payout shopper

Initiate a server-to-server POST request with the collected card, payment and billing data. The payment details are verified with the issuer, and the funds are credited to the shopper's account. The response to a successful request is an id that should be stored and used later in refunding the credited amount if required.


Payment rebill

Payment rebill means charging a shopper the right amount for something they bought from you. You may need to do this in three cases:

  • Estimated and incremental authorizations: This occurs when the final sale price differs from the estimated price at the time of purchase. For instance, if you’re selling a service like a taxi ride or a hotel room, the exact amount may not be known until the service is fully rendered.
  • Incorrect refund: This happens when you refund a shopper an amount greater than what they paid. For example, if a product sold for $10 is mistakenly refunded for $20.
  • Incorrect chargeback: This arises when a shopper files for a chargeback (a request for a refund) but isn’t entitled to it. For instance, if they assert that they didn’t receive the product or service, but you possess evidence to the contrary.
Rebill payments help prevent shopper confusion and financial loss on your part.

As for why to use a rebill instead of a chargeback reversal, it’s important to note that these two processes serve different purposes. A chargeback reversal is used when a merchant disputes a chargeback and the issuing bank rules in their favor, returning the funds to the merchant. On the other hand, a rebill is used when a merchant needs to charge a customer again, often due to the reasons mentioned above.

To know which acquirers or payment methods do support payment rebill, please reach out to your Customer Success Manager.

How it works

Perform debit payment

Send the debit request with the collected card data.

Rebill the authorized payment

Send the rebill request over authorized payment.

Transactions:
DB
DB
RB
RB

1. Perform debit payment

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. Rebill the authorized payment

Initiate a server-to-server POST request using the id of a successfully authorized payment. In this scenario, the merchant may incorporate additional charges that were not part of the original authorization. This could be due to extra services or products purchased.

It’s important to note that the amount of a rebill transaction is indeed on top of the initially authorized and captured amount. This means that if the original transaction was for $100, and there’s an additional charge of $20, the total amount charged to the customer would be $120. The rebill transaction allows the merchant to capture the additional $20 without requiring a new authorization from the customer.

Sample request: