Card recurring payments

Merchant-Initiated Transactions (Merchant Initiated Transactions – MIT) are common in business models where payments are performed at a later time compared to the initial purchase moment.

In these scenarios, the buyer authorizes the merchant to execute future charges by accepting the terms and conditions defined in the contractual agreement between the parties.

Use cases

Some examples include: bill payments, subscriptions, and consumption-based business models.

To properly manage this type of payment, it is necessary to distinguish and correctly use the following transaction types:

Customer Initiated Transaction (CIT)
Represents the first transaction in the recurring payments flow.
The customer is required to complete Strong Customer Authentication (SCA) in order to verify the payer’s identity and generate the reference identifier needed to process subsequent transactions, which will occur when the customer is not present.
Merchant Initiated Transaction (MIT)
Transactions initiated by the merchant without the buyer being present, in accordance with agreements and conditions previously defined and accepted by the customer.

Regulatory scope

MIT transactions are considered out of scope for PSD2 and therefore do not require two-factor authentication.

Integration guidelines

Fabrick Payment Orchestra supports two types of Merchant Initiated Transaction (MIT). For both types, an initial transaction is required, which we will refer to as First (CIT), and which requires customer authentication (SCA).

Following the initial transaction, the merchant executes a series of subsequent transactions, called Next (MIT), which are charged to the customer based on the service subscription, intended as the contractual agreement between the parties.

Next transactions share the following requirements:

There must be an agreement between merchant and buyer authorizing the merchant to charge the customer.
Each Next transaction must include in the request a reference to the initial First transaction.
Each Next transaction must be submitted with the same shopLogin used for the First transaction, as it is not possible to reference a First transaction generated on a different shopLogin.
It is not possible to submit a Next transaction whose first First transaction has been cancelled, as the recurring chain would no longer be valid.
The First transaction referenced by subsequent Next transactions must be authenticated via Strong Customer Authentication (SCA).

Tokenization for Next transactions

To process transactions when the customer is not in session (MIT), during the initial transaction (CIT) you must request the tokenization service in order to obtain the card token to be used for subsequent transactions.

Recurring transactions

Recurring transactions are indicated when the payment amount is fixed and the charging frequency is defined by a constant periodicity.
This type is typically used for subscription-based business models, such as digital services or paid content.

Recurring transactions enable structured and predictable payment management, making them ideal for scenarios where amounts and due dates are known and remain unchanged over time.

Fixed amount and periodicity
Recurring transactions involve charges with a fixed amount and a defined schedule of due dates.
Unscheduled transactions

Unscheduled transactions are characterized by variable amounts and variable periodicity.
This type is particularly suitable for usage-based business models, for managing no-show fees, and for applying penalties, for example in case of damage to rented goods.

Compared to recurring transactions, this integration mode offers greater flexibility, with fewer constraints in terms of configuration and payment management.

Variable amount and periodicity
Unscheduled transactions allow charging variable amounts without a fixed schedule of due dates.

First flow (CIT)

To initialize a recurring payment, the customer must enter their card details within the Fabrick payment page or via a custom payment page provided by the merchant on their website.

If the card has already been tokenized in a previous phase, it is possible to use the token to process the transaction, avoiding a new data entry by the customer.

Setting the transaction type

To indicate to the system that a transaction is part of a series of recurring payments, and specifically that it is the first transaction (First), you must add the transDetails object to the request and set the type field to one of the following values:
- 01F – Recurring transactions
- 03F – Unscheduled transactions

First transaction fields

Depending on the selected recurring-payment type, below are the fields to set in the request, to be used in addition to the mandatory fields required to perform the payment/create call, necessary for correct transaction processing.

Recurring transactions

Object	Field	Description
`transDetails`	`type`	Set to `01F` to indicate initialization of a recurrence with fixed amount and fixed periodicity
`transDetails`	`authenticationAmount`	Maximum expected amount according to the terms and conditions of the agreement between the parties
`transDetails.recurringTransaction`	`expiry`	Agreement expiration date
`transDetails.recurringTransaction`	`frequency`	Minimum number of days between one payment and the next

Unscheduled transactions

Object	Field	Description
`transDetails`	`type`	Set to `03F` to indicate initialization of a recurrence with variable amount and/or periodicity
`transDetails`	`authenticationAmount`	Maximum expected amount according to the terms and conditions of the agreement between the parties

For both transaction types, in response to the payment/create call Fabrick returns the identifier paymentID. Once the transaction is completed successfully, the paymentID can be used as a reference for subsequent Next transactions.

Handling the initial amount

It is not uncommon for a service to provide a free trial period or a deferred charge, processed at a later time than when the customer is in session. To correctly manage this scenario, you can set the amount field of the initial transaction to zero.

When the initial amount is 0.00, the request is defined as ASI and you must include the authenticationAmount field, which must be set to the maximum amount expected under the contractual agreements for subsequent payments. This value defines the maximum amount authorized for future recurring Next transactions.

The amount indicated in authenticationAmount may be displayed to the buyer during the authentication process, depending on the bank’s configurations.
Alternatively, the amount in the amount field may be shown.

Maximum authorized amount
If authenticationAmount is not set, if only amount is set, or if the amount in amount is greater than the one in authenticationAmount, the system will use the amount value as the maximum authorized amount for subsequent recurring transactions and, at the same time, the initial charge will be performed for the amount indicated in amount.

ASI (Account Status Inquiry)
This operation is aimed at verifying the card: it is not possible to capture or cancel the transaction.

Acquirer limitation
You can request an initial transaction with a 0.00 € amount only using Banca Sella or Shift4 as acquirer.
Card data and token handling

A First transaction can be submitted in two ways, depending on whether the card token is already available or not.
- With token
  
  If the card token was generated previously, it is not necessary to show the payment page to the customer.
  In this case, the First transaction can be handled entirely server-side, using the API Only integration, redirecting the buyer to the 3DS authentication page when required.
  
  This mode is ideal when the card has already been registered (tokenized) during a previous transaction.
- Without token
  
  If the token is not available, you must show the Fabrick payment page, or provide a form on your site to allow the customer to enter payment data.
  
  During the First transaction, the tokenization service will also be requested, in order to obtain a token to use for subsequent Next transactions.
  
  To enable tokenization, you must add the requestToken field to the payment/create call and set it to MASKEDPAN.
  
  Once the transaction and related authentication are completed, by querying the system through the payment/detail API you can retrieve the generated token and associate it with the buyer and the activated service.
note
- Build your custom payment page using API Only.
- On this page you can find more information about the Tokenization service.
Mandatory buyer notice
The First (CIT) flow requires the card to be tokenized: the buyer must therefore be informed that their card data will be tokenized before the transaction is submitted.
- If you collect card data through a Fabrick solution (payment page or Web Component), the notice is already handled: the message is displayed automatically on the page.
- If you use a custom payment page (API Only), the notice is the merchant's responsibility.
The messages displayed by Fabrick solutions are described in the Tokenization section.
Authentication handling

During the First transaction flow, Strong Customer Authentication (SCA) is always required.
It is not possible to request any exemption, regardless of:
- the integration mode used
- the availability of the card token

How to handle authentication

Fabrick payment page
If the integration is via the Fabrick payment page, customer authentication is handled directly by Fabrick.
API Only integration
In the API Only integration, handling the redirect for authentication is the merchant’s responsibility.
After the payment/submit call:
- If the card supports authentication protocols: the system returns error 8006 (Verify By Visa), requesting cardholder authentication. Using the link in payload.userRedirect.href, you can redirect the customer to their bank’s authentication flow.
- If the card does not support authentication protocols: you immediately obtain the final outcome of the transaction without needing to call payment/detail for additional information.

Mandatory authentication

Customer authentication is a fundamental step for subscription and validation of the recurrence.

Payment completion

Once the customer completes the authentication phase with their bank, they will be redirected to the success/failure URL defined by the merchant.

At the same time, the system also sends a server-to-server (S2S) notification to the merchant back-end containing the final outcome of the operation.

This allows the merchant to update the payment status even if the customer does not return to the site.

After payment completion, you can use the payment/detail endpoint to obtain all transaction information and store the data needed to manage possible recurring Next payments.

Once the First transaction is completed and the required data is stored, you can proceed with capture or refund/void of the authorized amount.

Transactions with a 0.00 € amount (ASI)

If the First transaction amount is 0 (ASI), the system does not allow cancelling the transaction.
Cancelling would break the payment chain and prevent execution of future Next transactions.
Transactions with an amount greater than zero and shopLogin with separated MOTO

When the First transaction amount is greater than zero and the shopLogin is configured with separated MOTO, it is equally important not to cancel the transaction via the payment/cancel API or the Fabrick Dashboard. Cancelling would invalidate the First transaction, blocking the possibility to execute future Next recurrences.

If it is necessary to refund the customer, you can capture the full amount of the transaction and then execute a refund. In this way, the recurrence chain remains active, enabling correct execution of subsequent Next transactions.

Warning
It is essential never to cancel the First transaction (neither via payment/cancel API nor via dashboard).
Cancelling would make it impossible to execute recurring Next transactions.

Integration

Payment Page - Unscheduled - Without token#

To initialize a recurring payment using the Fabrick Payment Page

Creating the payment request

Use the server-side payment/create call to generate the payment request, ensuring that you include the requestToken field in the body, set to MASKEDPAN to request card tokenisation.
This approach ensures security in generating the request payload and using the API key.

Key data to save for future recurrences:
- authenticationAmount
Integration mode
Depending on the integration mode chosen, the payment page can be presented via the Pay By Link service, or through the Lightbox or Web Components solution.
The example below uses Pay By Link mode; if integrating via Lightbox or Web Components, simply remove the paymentChannel object from the call.

POST payment/create – First 03F

Request
```
POST /api/v1/payment/create
Host (sandbox): sandbox.gestpay.net
Host (produzione): ecomms2s.sella.it
Authorization: apikey ****************
Content-Type: application/json
```
```
{
    "shopLogin": "GESPAY12345",
    "amount": "0",
    "currency": "EUR",
    "shopTransactionID": "FBK-C03F_OrderID",
    "paymentChannel": { "channelType": ["LINK"] }, // Payment link request (PBL)
    "paymentType": ["CREDITCARD"], // Payment request by card only
    "requestToken": "MASKEDPAN", // Request token generation
    "transDetails": {
        "type": "03F",
        "authenticationAmount": "100"
    }
}
```

Payment page presentation

In response to the payment/create call, depending on the integration used, you will obtain:

Lightbox or Web Components

paymentToken
paymentID

Pay By Link

paymentToken
paymentID
href (link to redirect the customer to the payment page)

The values returned by the call are necessary to:

present the payment page via Lightbox or Web Components integration
manage the customer's redirection to the payment page, using the link in payload > userRedirect > href via Pay By Link integration
use the payment/detail call to verify the payment outcome and retrieve the token information

The system returns the paymentToken and paymentID values, which must be used in the dedicated JavaScript to display the payment page.

Response

{
    "error": {
        "code": "0",
        "description": "request correctly processed"
    },
    "payload": {
        "paymentToken": "8a901523-67a5-4aca-bbd2-c7c412934289",
        "paymentID": "1360119538182",
        "userRedirect": null,
        "qrCode": null
    }
}

Pay By Link Integration

The link to be used to redirect the customer to the payment page is located in the field: payload > userRedirect > href.

Response

{
    "error": {
        "code": "0",
        "description": "request correctly processed"
    },
    "payload": {
        "paymentToken": "8a901523-67a5-4aca-bbd2-c7c412934289",
        "paymentID": "1360119538182",
        "userRedirect": {
            "href": "https://sandbox-web.axerve.com/orchestra/checkout/a/dc1e181fe487435c86a09120550327a9/b/925e8ec8839a1baf2da2d49f5ecf87cfdfd671d0486f0c9f5932b5e3f751015cdbd5cf51-3a24-4a5b-93d9-999b5b191f54Pbt52obGzvypZVa-GFVGk3cRg9u-lKsJhyN-QqmbrdW3e6kF1HuES-vViOdWiDq18MhptroRU9fSvbyJHOQxxbOyEYB43hLm7PlaAjHOJeG58RIRuKBMwY40yyMjt-JmYZuWOGxbUnbNfRjYw2vKFro5sZU3"
        },
        "qrCode": null
    }
}

Payment verification and completion

After the buyer has completed the payment:

Pay By Link integration The user is redirected to the success/failure URL.
Web Components integration The user is redirected to the success/failure URL.
Lightbox Integration
- If you use the callback object, the system does not redirect: the URL will be available in the responseURL field in the received object.
- If you do not use the callback object, the system automatically redirects to the success/failure URL.

For both types of integration, the system will also send an S2S notification containing the payment result, together with the paymentToken and paymentID data.

Example of redirect URL and S2S notification:

https://merchant-url.com?a=GESPAY12345&Status=OK&paymentID=1360119538182&paymentToken=8a901523-67a5-4aca-bbd2-c7c412934289

Use the payment/detail API to verify the payment outcome and obtain the card token.

Key data to save for future recurrences:

paymentID
TokenValue

Once the payment has been confirmed as successful, you can proceed with the capture or reversal of the transaction and token management.

`GET payment/detail` – Esito pagamento + informazioni token

Request

GET /api/v1/payment/detail/1360119538182 (PaymentID)
Host (sandbox): sandbox.gestpay.net
Host (produzione): ecomms2s.sella.it
Authorization: apikey **************** (or) PaymentToken: 8a901523-67a5-4aca-bbd2-c7c412934289
Content-Type: application/json

Response

{
    "error": {
        "code": "0",
        "description": "request correctly processed"
    },
    "payload": {
        "transactionType": "detail",
        "transactionResult": "APPROVED",
        "transactionState": "AUT",
        "transactionErrorCode": "0",
        "transactionErrorDescription": "Transaction correctly processed",
        "bankTransactionID": "492",
        "shopTransactionID": " FBK-C03F_OrderID",
        "shopTransactionID_2": "",
        "authorizationCode": "188190",
        "paymentID": "1360119538182",
        "currency": "EUR",
        "country": "ITALIA",
        "company": "VISA",
        "tdLevel": "FULL",
        "threeDS": {
            "authenticationResult": {
                "authenticationLevel": "2C",
                "authenticationStatus": "Y",
                "authStatusReason": "",
                "challengeResultTransStatus": "",
                "XID": "12e6e4ce-8ccc-49f9-b5a4-18b486f1d29d",
                "AV": "MTIzNDU2Nzg5MDA5ODc2NTQzMjE=",
                "ECI": "05",
                "AVAlgorithm": "",
                "threeDsVersion": "2.1.0"
            },
            "transDetails": {
                "authData": "",
                "authMethod": "02",
                "authTimeStamp": "202407111313",
                "acsID": "48a413bf-fe27-4de2-a39e-dc6039e4aef7"
            }
        },
        "events": [
            {
                "event": {
                    "eventtype": "AUT",
                    "eventamount": "0.00",
                    "eventdate": "11/07/24 13:13:56",
                    "eventARN": "",
                    "eventID": "",
                    "eventReferred": ""
                }
            }
        ],
        "buyer": {
            "name": "",
            "email": ""
        },
        "risk": {
            "riskResponseCode": "",
            "riskResponseDescription": ""
        },
        "customInfo": null,
        "alertCode": "",
        "alertDescription": "",
        "cvvPresent": "TRUE",
        "dcc": null,
        "maskedPAN": "",
        "paymentMethod": "VISA",
        "productType": "Credit",
        "tokenDetails": {
            "TokenValue": "40ZUU8NXALR33101",
            "TokenExpiryMonth": "05",
            "TokenExpiryYear": "27",
            "TokenProvider": "AXERVE",
            "CardDetails": {
                "CardSuffix": "3101",
                "CardExpiryMonth": "05",
                "CardExpiryYear": "27",
                "CardHolderName": null
            },
            "CardAssets": {
                "CardArt": {
                    "Type": null,
                    "MediaContents": null,
                    "Height": null,
                    "Width": null
                },
                "BrandLogo": {
                    "Type": null,
                    "MediaContents": null,
                    "Height": null,
                    "Width": null
                }
            }
        },
        "fraudPrevention": {
            "check": "FALSE",
            "state": "",
            "description": "",
            "order": ""
        },
        "automaticOperation": {
            "type": "CAN",
            "date": "05/08/24 00:00:00",
            "amount": "0"
        }
    }
}

Next flow (MIT)

MIT transactions represent the subsequent payments after the initial (First) transaction and are executed in the customer’s absence, based on the authorization previously granted during the First transaction.

Execution of recurring Next transactions is not handled automatically by Fabrick: the merchant must schedule, initiate, and manage each recurring charge, in compliance with contractual agreements and conditions accepted by the customer during service subscription.

Setting the transaction type

To indicate to the system that a transaction represents a subsequent payment in a recurrence, you must add the transDetails object to the request and set the type field to one of the following values:
- 01N – Recurring transactions
- 03N – Unscheduled transactions
Next transaction fields

To collect a recurring payment through a Next transaction, in the payment/create call you must:
- set the type parameter with the correct value;
- include the reference to the authenticated initial First transaction.
To provide the system with the paymentID of the First transaction, you must add the transDetails.previousTransDetails object and set the paymentID field, in addition to the mandatory fields required for the payment/create operation.

Fields required to link to the First transaction

Object Field Description
transDetails type Set to 01N / 03N
transDetails.previousTransDetails paymentID Identifier of the First (CIT) transaction

ShopLogin to be used to specify the First
The paymentID of the First transaction is valid only on the shopLogin where the transaction was generated.
It is therefore not possible to submit a Next transaction on a different shopLogin, the reference to the First transaction could not be resolved and the transaction could not be processed.
If you need to collect the recurring payment on a different shopLogin, you must generate a new authenticated First transaction (CIT) on the new shopLogin and use the resulting paymentID as the reference for all subsequent Next transactions.

For Next transactions the customer is not present and cannot re-enter card details.
For this reason, in addition to referencing the First transaction in payment/create, in the payment/submit call you must use the card token generated (or used) during the First transaction.

Using the token allows the system to correctly process the transaction, avoiding asking the buyer again for payment details.

In the payment/submit call, the token must be placed inside the paymentTypeDetails.creditcard object, setting the token field.

Fields required to send the token in payment/submit

Object Field Description
paymentTypeDetails.creditcard token Card token used during the First transaction
Transaction handling

For this type of transaction, it is not necessary to show the payment page to the customer again. Once the initial First transaction is successfully completed, the system already has all information needed to manage subsequent recurrences (Next).

In exceptional cases, the customer’s bank may require a new authentication. In this case, the system will return error 8026 – Soft Decline in response to the payment/submit call.
When this happens, you must contact the customer and initialize a new First transaction in order to obtain a new identifier (paymentID) to use for future Next transactions.

Operational note
To execute MIT transactions, no interaction from the customer is required and the payment page does not need to be presented.
Payment completion

Once the Next payment request is sent to Fabrick services, the system immediately communicates the payment outcome. Alternatively, you can use the payment/detail API to query the transaction. To correctly complete the recurrence collection flow, you must:
- Verify that no SCA is requested, since Next transactions are executed when the customer is not present;
- Verify the response outcome returned by Fabrick, ensuring the transaction was processed successfully;
- Manage the token correctly, ensuring continuity of the recurring payment chain.
note
On this page you can find more information about token management: token

Object	Field	Description
`transDetails`	`type`	Set to `01N` / `03N`
`transDetails.previousTransDetails`	`paymentID`	Identifier of the First (CIT) transaction

Object	Field	Description
`paymentTypeDetails.creditcard`	`token`	Card token used during the First transaction

Integration

API Only - Unscheduled - With token#

To perform a recurring payment using API Only, follow the steps below

Creating the payment request

Use the server-side payment/create call to create the payment request. This approach ensures security in generating the request payload and using the API key.

Set the type parameter to 03N to indicate to the system that this is a Next transaction and use the PaymentID generated by the First transaction.

Prerequisite: Initial transaction of type First (03F) successfully completed.

In response to this call, you will obtain two values: paymentToken and paymentID

These values are used to:

make the server-side payment/submit call to initiate payment
(optional) use payment/detail to check the payment outcome and retrieve token information.

`POST payment/create` – Next 03N

Request

POST /api/v1/payment/create
Host (sandbox): sandbox.gestpay.net
Host (produzione): ecomms2s.sella.it
Authorization: apikey ****************
Content-Type: application/json

{
    "shopLogin": " GESPAY12345",
    "amount": "100",
    "currency": "EUR",
    "shopTransactionID": "FBK-C03N_OrderID",
    "transDetails": {
        "type": "03N",
        "previousTransDetails": {
            "paymentID": "1360119538182"
        }
    }
}

Response

{
    "error": {
        "code": "0",
        "description": "request correctly processed"
    },
    "payload": {
        "paymentToken": "7ebd948a-c9ad-44c9-ac43-02b0beb55a7a",
        "paymentID": "1541109548247",
        "userRedirect": null,
        "qrCode": null
    }
}

Submitting payment details

After obtaining the paymentToken and paymentID, use the server-side payment/submit call to send the card token to Fabrick. Ensure that you populate the paymentTypeDetails > creditcard > token field with the card token generated or used during the initial First (03F) transaction.

`POST payment/submit` – Next 03N

Request

POST /api/v1/payment/submit
Host (sandbox): sandbox.gestpay.net
Host (produzione): ecomms2s.sella.it
PaymentToken 7ebd948a-c9ad-44c9-ac43-02b0beb55a7a
Content-Type: application/json

{
    "shopLogin": "GESPAY12345",
    "paymentType": "CREDITCARD",
    "shopTransactionID": "FBK-S03N_OrderID",
    "paymentTypeDetails": {
        "creditcard": {
            "token": "40ZUU8NXALR33101"
        }
    }
}

Following the payment/submit call, three main scenarios may occur:

The transaction was processed successfully

The payment outcome is returned immediately in response to the call.

Response

{
    "error": {
        "code": "0",
        "description": "request correctly processed"
    },
    "payload": {
        "transactionType": "submit",
        "transactionResult": "OK",
        "transactionErrorCode": "0",
        "transactionErrorDescription": "Transaction correctly processed",
        "bankTransactionID": "569",
        "shopTransactionID": "FBK-C03N_OrderID",
        "shopTransactionID_2": "",
        "authorizationCode": "188190",
        "paymentID": "1360119538182",
        "currency": "EUR",
        "country": "ITALIA",
        "company": "VISA",
        "tdLevel": "",
        "buyer": {
            "name": "",
            "email": ""
        },
        "risk": {
            "riskResponseCode": "",
            "riskResponseDescription": ""
        },
        "customInfo": {},
        "alertCode": "",
        "alertDescription": "",
        "cvvPresent": "Y",
        "maskedPAN": "",
        "paymentMethod": "",
        "productType": "Credit",
        "token": "",
        "tokenExpiryMonth": "",
        "tokenExpiryYear": "",
        "userRedirect": {
            "href": "https://sandbox.gestpay.net/pagam/AxerveThankYou.aspx"
        }
    }
}

The bank requires new authentication of the cardholder

The transactionErrorCode field returns the value 8026
You must contact the customer and initiate a new First transaction in order to obtain a new identifier (paymentID) to be used for future Next transactions.

Response (SCA request – code 8026)

{
    "error": {
        "code": "0",
        "description": "request correctly processed"
    },
    "payload": {
        "transactionType": "submit",
        "transactionResult": "KO",
        "transactionErrorCode": "8026",
        "transactionErrorDescription": "Soft decline - Cardholder authentication required",
        "bankTransactionID": "569",
        "shopTransactionID": "FBK-C03N_OrderID",
        "shopTransactionID_2": "",
        "authorizationCode": "",
        "paymentID": "1360119538182",
        "currency": "EUR",
        "country": "ITALIA",
        "company": "VISA",
        "tdLevel": "",
        "buyer": {
            "name": "",
            "email": ""
        },
        "risk": {
            "riskResponseCode": "",
            "riskResponseDescription": ""
        },
        "customInfo": {},
        "alertCode": "",
        "alertDescription": "",
        "cvvPresent": "Y",
        "maskedPAN": "",
        "paymentMethod": "",
        "productType": "Credit",
        "token": "",
        "tokenExpiryMonth": "",
        "tokenExpiryYear": "",
        "userRedirect": {
            "href": "https://sandbox.gestpay.net/pagam/AxerveThankYou.aspx"
        }
    }
}

Error during request
- The response contains the error object with:
  - error.code: error code
  - error.description: error description
- See the complete list of errors
Response
```
{
    "error": {
        "code": "1165",
        "description": "Token not found"
    },
    "payload": {}
}
```

Payment verification and completion

Once the Next payment request has been sent to Fabrick services, the system immediately returns the transaction result. At the same time, an S2S notification is sent containing the payment result together with the paymentToken and paymentID data. In addition, you can optionally use the payment/detail API to query the transaction, verify the payment result and obtain token information.

Example of redirect URL and S2S notification:

https://merchant-url.com?a=GESPAY12345&Status=OK&paymentID=1541109548247&paymentToken=8a901523-67a5-4aca-bbd2-c7c412934289

Once the payment has been confirmed as successful, you can proceed with the capture or reversal of the transaction and token management.

`GET payment/detail` – Result of payment + token information

Request

GET /api/v1/payment/detail/1360119538182 (PaymentID)
Host (sandbox): sandbox.gestpay.net
Host (produzione): ecomms2s.sella.it
Authorization: apikey **************** (or) PaymentToken: 8a901523-67a5-4aca-bbd2-c7c412934289
Content-Type: application/json

Response

{
    "error": {
        "code": "0",
        "description": "request correctly processed"
    },
    "payload": {
        "transactionType": "detail",
        "transactionResult": "APPROVED",
        "transactionState": "AUT",
        "transactionErrorCode": "0",
        "transactionErrorDescription": "Transaction correctly processed",
        "bankTransactionID": "569",
        "shopTransactionID": " FBK-C03N_OrderID",
        "shopTransactionID_2": "",
        "authorizationCode": "188190",
        "paymentID": "1360119538182",
        "currency": "EUR",
        "country": "ITALIA",
        "company": "VISA",
        "tdLevel": "FULL",
        "threeDS": {
            "authenticationResult": {
                "authenticationLevel": "2C",
                "authenticationStatus": "Y",
                "authStatusReason": "",
                "challengeResultTransStatus": "",
                "XID": "12e6e4ce-8ccc-49f9-b5a4-18b486f1d29d",
                "AV": "MTIzNDU2Nzg5MDA5ODc2NTQzMjE=",
                "ECI": "05",
                "AVAlgorithm": "",
                "threeDsVersion": "2.1.0"
            },
            "transDetails": {
                "authData": "",
                "authMethod": "02",
                "authTimeStamp": "202407111313",
                "acsID": "48a413bf-fe27-4de2-a39e-dc6039e4aef7"
            }
        },
        "events": [
            {
                "event": {
                    "eventtype": "AUT",
                    "eventamount": "0.00",
                    "eventdate": "11/07/24 13:13:56",
                    "eventARN": "",
                    "eventID": "",
                    "eventReferred": ""
                }
            }
        ],
        "buyer": {
            "name": "",
            "email": ""
        },
        "risk": {
            "riskResponseCode": "",
            "riskResponseDescription": ""
        },
        "customInfo": null,
        "alertCode": "",
        "alertDescription": "",
        "cvvPresent": "TRUE",
        "dcc": null,
        "maskedPAN": "",
        "paymentMethod": "VISA",
        "productType": "Credit",
        "tokenDetails": {
            "TokenValue": "40ZUU8NXALR33101",
            "TokenExpiryMonth": "05",
            "TokenExpiryYear": "27",
            "TokenProvider": "AXERVE",
            "CardDetails": {
                "CardSuffix": "3101",
                "CardExpiryMonth": "05",
                "CardExpiryYear": "27",
                "CardHolderName": null
            },
            "CardAssets": {
                "CardArt": {
                    "Type": null,
                    "MediaContents": null,
                    "Height": null,
                    "Width": null
                },
                "BrandLogo": {
                    "Type": null,
                    "MediaContents": null,
                    "Height": null,
                    "Width": null
                }
            }
        },
        "fraudPrevention": {
            "check": "FALSE",
            "state": "",
            "description": "",
            "order": ""
        },
        "automaticOperation": {
            "type": "CAN",
            "date": "05/08/24 00:00:00",
            "amount": "0"
        }
    }
}

Integration guidelines​

Recurring transactions​

Unscheduled transactions​

First flow (CIT)​

Setting the transaction type​

First transaction fields​

Handling the initial amount​

Card data and token handling​

With token​

Without token​

Authentication handling​

How to handle authentication​

Payment completion​

Transactions with a 0.00 € amount (ASI)​

Transactions with an amount greater than zero and shopLogin with separated MOTO​

Integration​

Payment Page - Unscheduled - Without token#

Creating the payment request​

POST payment/create – First 03F​

Payment page presentation​

Lightbox or Web Components integration​

Pay By Link Integration​

Payment verification and completion​

GET payment/detail – Esito pagamento + informazioni token​

Next flow (MIT)​

Setting the transaction type​

Next transaction fields​

Fields required to send the token in payment/submit​

Transaction handling​

Payment completion​

Integration​

API Only - Unscheduled - With token#

Creating the payment request​

POST payment/create – Next 03N​

Submitting payment details​

POST payment/submit – Next 03N​

The transaction was processed successfully​

The bank requires new authentication of the cardholder​

Error during request​

Payment verification and completion​

GET payment/detail – Result of payment + token information​

Integration guidelines

Recurring transactions

Unscheduled transactions

First flow (CIT)

Setting the transaction type

First transaction fields

Handling the initial amount

Card data and token handling

With token

Without token

Authentication handling

How to handle authentication

Payment completion

Transactions with a 0.00 € amount (ASI)

Transactions with an amount greater than zero and shopLogin with separated MOTO

Integration

Creating the payment request

`POST payment/create` – First 03F

Payment page presentation

Lightbox or Web Components integration

Pay By Link Integration

Payment verification and completion

`GET payment/detail` – Esito pagamento + informazioni token

Next flow (MIT)

Setting the transaction type

Next transaction fields

Fields required to send the token in `payment/submit`

Transaction handling

Payment completion

Integration

Creating the payment request

`POST payment/create` – Next 03N

Submitting payment details

`POST payment/submit` – Next 03N

The transaction was processed successfully

The bank requires new authentication of the cardholder

Error during request

Payment verification and completion

`GET payment/detail` – Result of payment + token information