Server to Server - Token Usage

A returning customer can be allowed to pay with a previously tokenised card that is associated with his account on the merchant store either using AUTH or PURS.

The token usage may be depicted in the following steps:

  • The merchant shows a list of the cards available to the customer using masked PAN and expiration date previously sent by SPG in the tokenisation flow.
  • The customer recognizes the card and inputs the card CVV.
  • The merchant performs the checkout and payment.

Note: it is a good practice to, as an alternative choice to saved cards, allow the customer to use a new card for payment and save it according to his will-

How it Works

Flow - Card token usage

Use the one time purchase flow when your customer is charged immediatelly when buying goods or services.

This page requires an SVG viewer.

See the World Wide Web Consortium (W3C) Web site for more information on SVG and available viewers.
Starting by creating the checkout

First, perform a server-to-server POST request, the same as Form Integration, to prepare the checkout with the required data, where you should include the payment type, amount, currency and payment methods allowed.

If already sure that only Card payment is required, then only include "CARD" in the transaction.paymentMethod list.

The JSON of your POST body, can be composed of various Complex Types:

"merchant": {

"terminalId": {{terminalId}},

"channel": "web",

"merchantTransactionId": "{{mti}}"

"transactionDescription": "transaction short description"

"shopURL" : ""


For more info check API Market

"transaction": {

"transactionTimestamp": "Current Date",

"description": "transaction statement description",

"moto": false,

"paymentType": "PURS",

"amount": {

"value": 50.50,

"currency": "PLN"


"paymentMethod": [




For more info check API Market

"customer": {

"customerInfo": {

"customerName": "Client Name",

"customerEmail": "",

"shippingAddress": {

"street1": "Street address 1",

"street2": "Street address 2",

"city": "Lisbon",

"postcode": "1200-999",

"country": "PT"


"billingAddress": {

"street1": "Street address 1",

"street2": "",

"city": "Lisbon",

"postcode": "1200-999",

"country": "PT"




For more info check API Market

"recurringTransaction": {

"validityDate": "2022-09-28T17:37:31.4095147+00:00",

"amountQualifier": "DEFAULT",

"description" : "My transaction -> Order XPTO"


For more info check API Market

The response to a successful request is a JSON with a transactionID, which is required in the second step to create a transaction.

With the transactionID, will be present as well a transactionSignature that will be used on the following step


Request URL:
Request Headers:

Request Body:

Expected Response

A success response comprises of an HTTP-200 status, a transactionID and a transactionSignature

Any other HTTP status signals an unsuccessful request. The following statuses may occur:

  • HTTP-400 (Bad Request): The JSON payload is not matching the API definition or some mandatory HTTP headers are missing. Please check in API Market for the correct syntax.
  • HTTP-401 (Unauthorized): The Authorisation: Bearer token is not invalid/expired or not associated with the Terminal used. Please check in SIBS Backoffice under the Credentials if the token is valid, and create a new one if needed.
  • HTTP-403 (Forbidden): The ClientID set on the X-IBM-Client-Id HTTP header is not valid or does not possess a valid subscription to the API. Please check in SIBS Backoffice under the SPG APP 2.0 if the ClientID is correct. If the problem persists contact SIBS Gateway support for a ClientID reset.
  • HTTP-405 (Method Not Allowed): The HTTP Method used is not matching any of the API definitions available. Please check in API Market for the correct HTTP Method.
  • HTTP-429 (Too Many Requests): The API calls rate limit has been exceeded. Please check in API Market for information on the rate limits that apply to the API.
  • HTTP-500 (Internal Server Error): The API call has failed... and its most likely on our side. You should retry the operation, and if the problem persists contact SIBS Gateway support for assistance.
  • HTTP-503 (Service Unavailable): The API call is not currently available. Usually we are always on, but short availability issues may occur during scheduled maintenance.
Next the transaction has to be generated:

Note that the following request needs an Authorisation Header with the transactionSignature returned from checkout operation.

In this requests, the Bearer Token is replaced by the checkout response transactionSignature.


Authorisation: Digest {transactionSignature}

Request URL:


Request Headers:

Authorisation: Digest {transactionSignature}

Request Body:

Expected Response

A successful technical response comprises of an HTTP-200 status and a returnStatus.statusCode="000".

The paymentStatus in the response informs on whether the transaction itself was accepted, declined, still pending a final result, or requiring additional action to be taken.

  • Success: The purchase has been processed successfully and the customer has been debited.
  • Declined: The purchase has been declined.
  • Pending: The final result of the purchase is not yet known. You will need to inquiry on the status of this transaction until it reaches a final state, or you decide to cancel it.
  • Partial: The purchase is partially accepted, but requires additional actions to the completed (e.g. 3D-Secure authentication). The actionResponse element is provided for instructions on how to proceed.
Afterwards you can perform a Get Status

Once the payment has been processed, you can check the status of your transaction making a GET request.

The Authorisation HTTP header is set to the Bearer token as it was used in the initial Checkout.

Request URL:
Request Headers:

What's Next

Have a look at the other Card payment features you can use.