Stored Credentials

Stored credential (saved payment data, CoF, credential on file) is a unique secure token linking the payer's card data to their identifier in the merchant's system. The stored credential can be used for future purchases, so the cardholder doesn't have to enter card details again. Such transactions are called stored-credential transactions.

Types of stored credentials

Use getBindings.do. request to find out the stored credential type.

Payment service allows to create and use the following type of stored credentials:

• Common (C) – for payments that are not related to any plan or schedule. For example, when a customer makes a new order and pays for it using previously saved card data.
• Recurrent (R) – for payments that occurs on a fixed schedule. For example, monthly utility bills.
• Installment (I) – for payment by installments, when a customer pays a bill in small portions throughout a fixed period of time according to a payment plan.
• No type (null) – legacy type of stored credential that correspond to a stored credential of type C or R (the type is implicit). Used in compatibility mode. It is not possible to create a new stored credential with this type.

One card can have stored credentials of different types associated with it. Moreover, it can have multiple stored credentials for different installment.

The type of stored credential determines the API method used for payment. Using other methods will result in a payment error.

Transaction types

Stored-credential transactions belong to either of the two groups depending on the initiator of a transaction:

• CIT (Cardholder-initiated Transactions) – e-commerce transactions where a cardholder takes part in the payment. This group includes the following types of transactions:
  • C/CI – common initial transaction, when a common credential is stored for further payments.
  • RI – recurrent initial transaction, when a recurrent credential is stored for further recurring payments.
  • II – installment initial transaction, when an installment credential is stored for further payments by installments.
  • F – unscheduled transaction, performed by a cardholder using a common stored credential.
• MIT (Merchant-initiated Transactions) – e-commerce transactions performed by the merchant without participation of a cardholder. This group includes the following type of transactions:
  • U – unscheduled transaction performed using a common stored credential. For example, penalty charge. Note that there is no CVC or 3DS verification for such operation as a cardholder does not take part in it and cannot enter any data.
  • R - subsequent recurrent transaction that uses a recurrent stored credential.
  • I – subsequent installment transaction that uses an installment stored credential.

The payment service AntiDDOS Router provides stored credentials functionality for use in both CIT and MIT payments.

Payment Data Storage

Depending on the Partner's permissions, payment data can be stored:

• In the bank. In this case, the card data from the stored credential may or may not be available in the Payment Service: this affects the routing of payments. Payment data stored in the bank can be created using the regular or special Payment Service payment page, as well as through Payment Service API requests.
• On the Partner's side. This storage method can be used if the Partner complies with the PCI DSS standard requirements. Such a stored credential can only be created via API.

Routing

When creating stored credentials, the Payment Service AntiDDOS Router routes payment according to the current routing rules.

For subsequent payments using the stored credentials, the following routing options are available:

• Stored-credential transactions with payment data stored on the Partner's side is always routed according to the current rules.
• Card data extraction from stored credentials is NOT enabled or card data from stored credentials are NOT available in the Payment Service. In this case, the payment is always sent to the same Bank where the link was created for this clientId.
• Card data extraction from stored credential enabled and card data from stored credentials available in Payment Service. In this case, payments are routed as follows:

To modify your permissions and the way payment data are stored, contact support. To find out the current settings, use the /settings/getRouterParams.do request.

eCom Stored Credentials on the Bank's Side

eCom stored credentials are intended for one-time online transactions where the buyer uses saved card data to pay for a specific order. Using eCom stored credentials, both CIT (Customer Initiated Transactions) and MIT (Merchant Initiated Transactions) payments can be conducted. However, eCom stored credentials cannot be used for recurring payments or installment payments.

Creating an eCom Stored Credentials

An eCom stored credential can be created if the Partner has the required permissions from the banks.

The payment service AntiDDOS Router supports the following methods for creating stored credentials:

• When paying on the Payment Service payment page with card saving.
• On a special page for card saving. This method requires special configurations for the Partner. Contact support.
• When paying via API.
• Without payment using "features": ["VERIFY"] during registration.

Creating a stored credential on the Payment Service payment page

This option is implemented using a standard order registration register.do or registerPreAuth.do and the standard Payment Service payment page described on the page Integration via Redirect. In the registration request, it is mandatory to include clientId, and if you need to create a stored credential for recurring payments or installments, then additionally pass the parameters for these types of stored credentials (see the relevant sections).

An example of order registration for creating a regular (eCom) stored credential:

curl -X POST 'https://api.uat.all2pay.net/v1/register.do' 
-H 'Content-Type: application/json' \
--data-raw '{
    "orderNumber": "order_123463",
    "amount": 10000,
    "currency": "643",
    "language": "en",
    "returnUrl": "https://mybestmerchantreturnurl.com/",
    "userName": "test_user",
    "password": "test_user_password_",
    "clientId": 1010123
}'

Response example:

{
    "errorCode": "0",
    "formUrl": "https://router.rbsuat.com/wl/payment.html?mdOrder=2dc811e7-8d1c-407a-bd25-a4f41f96cc60&language=en",
    "orderId": "2dc811e7-8d1c-407a-bd25-a4f41f96cc60",
    "orderNumber": "order_123457"
}

After registering the order, the partner redirects the client to the payment page using the URL from the formUrl parameter:

The stored credential will be created depending on whether the Save Card checkbox is selected on the payment page. In this case, the stored credential will be "regular" (eCom) and cannot be used for recurring billing.

The payment service AntiDDOS Router does not impose restrictions on authorization or zero-amount payment verification. The success of these stored credential creation methods depends on the bank's processing center's support for these methods.

Creating a stored credential through a special card-saving page

In this option, a separate partner login intended for stored credentials creation should be used to register the order. This login has separate settings in the Payment Service that modify the regular payment page into a card saving page.

The scenario with a separate partner login and a special page can be used instead of creating a stored credential without payment if the bank does not support that feature.

When registering an order, either registerPreAuth.do (which will perform a hold) or register.do (which will perform fund withdrawal) is used. When creating a stored credential through a special page, the Partner independently decides which method to use. The most typical method involves holding 1..10 RUB using registerPreAuth.do.

When creating a stored credential with a special login:

• Mentioning clientId during order registration is mandatory.
• The allowedPaymentWays passed during registration is ignored and is always assumed to be ["CARD"].
• The client is shown a special page intended solely for card saving. This page has no attributes of a regular payment or payment method selection.
• After successful authorization (holding) using registerPreAuth.do, the Payment Service AntiDDOS Router does not automatically finalize the order (deposit.do). The Partner must independently finalize such orders if necessary.

• Automatic cancellation of the order (reverse.do) or refund (refund.do) is not performed either after authorization (holding) or withdrawal. The Partner must independently cancel such orders if necessary.

  To configure automatic cancellation of such orders after a certain period, contact technical support.

Creating a stored credential during API payment

A stored credential will be created during API payment if the following conditions are met:

• The Partner has the necessary permissions at the bank routing the payment.
• When registering the order (register.do, registerPreAuth.do, or instantPayment.do), clientId is provided, as shown in the above example.
• The bank routing the payment does not yet have eCom stored credentials with the card selected by the Client for payment.

Refer to the Direct Payments via API section for the payment procedure. After completing the payment process, the stored credential will be created.

To avoid creating a stored credential during payment, you need to pass the parameter bindingNotNeeded = true in the paymentOrder.do or instantPayment.do method.

Creating a stored credential without payment

To create a stored credential without payment, you need to send a request for order registration register.do, registerPreAuth.do, or instantPayment.do with the parameter "features": ["VERIFY"].

The VERIFY function is intended to verify that the payment card is used by its legitimate owner (non-payment authentication, NPA).

The amount parameter in the verification request can be set to 0. Even if a certain payment amount is provided in the request, it will not be deducted from the client's account.

After successful verification, the order is immediately transferred to the REVERSED (cancelled) status.

Example request:

curl -X POST 'https://api.uat.all2pay.net/v1/register.do' -H 'Content-Type: application/json' \ \n--data-raw '{
    "features": ["VERIFY"], 
    "orderNumber":"order_123556",
    "amount":1234,
    "currency":"643",
    "language":"ru",
    "returnUrl":"https://mybestmerchantreturnurl.com/",
    "userName":"test_user",    
    "password":"test_user_password", 
    "clientId":"123"
}'

Then the Client can enter card details as follows:

• On the Payment Service's payment page. In this case, you need to redirect the Client to the URL in the formUrl parameter received in the registration response. This is a special page for saving the card.

  

  If 3-D Secure is available for the card, verification of 3-D Secure will be performed after clicking the Save Card button.

• On the Partner's payment page. In this case, follow all the steps as for payment via API. For details, see the section Direct Payments via API.

The stored credential will be created after card verification is complete.

ID of the Created Stored Credential

Regardless of how the stored credential is created, its identifier is returned to the partner when requesting the order status getOrderStatusExtended.do in the bindingId parameter.

Example request:

curl -X POST 'https://api.uat.all2pay.net/v1/getOrderStatusExtended.do' -H 'Content-Type: application/json' \ \n--data-raw '{
    "orderId": "5ab8fb6a-421e-4396-9bf8-d7d77cc1e706",
    "userName": "test_user",
    "password": "test_user_password"
}'

Example response fragment:

...
"bindingInfo": {
    "bindingId": "baa2c8b4-afc3-7190-b05f-d17d08a8cc00",
    "clientId": "1010123"
}
...

You can also get a list of all stored credentials using the getBindings.do method.

Payment using eCom stored credentials

Payment with eCom Stored Credentials on the Payment Service Page

For payment using a standard (eCom) stored credential on the payment page, use the Redirect Integration scenario. On the payment page, a previously saved card can be selected for payment.

Payment with eCom Stored Credentials via API

For payment using a standard (eCom) stored credentials via API, you can use one of the following methods:

1. Register a new order using register.do or registerPreAuth.do and use the paymentOrderBinding.do method to pay for that order by providing the bindingId — the stored credential identifier obtained from the order status. See the payment scheme in the section Two-Request Integration Scheme
2. Use the instantPayment.do method to register and pay for the order by specifying the bindingId. More details on this method can be found in the section One-Request Integration Scheme

Example of a paymentOrderBinding.do request:

curl --request POST --url 'https://api.uat.all2pay.net/v1/paymentOrderBinding.do' --header 'Content-Type: application/json' \ \n--data-raw '{
    "userName": "test_user",
    "password": "test_user_password",
    "bindingId": "b86f5197-e8a1-724e-b2c1-54fe00a878e8",
    "amount": 10000,
    "clientId": 1010123,
    "mdOrder": "3f1f91bd-2924-44b2-a32a-b8c39b8b1c0c",
    "cvc": "123"
}'

If the payment request response includes parameters indicating a need for 3DS verification ("is3DSVer2": true or acsUrl and paReq), follow the steps for 3DS Authentication.

Deleting eCom stored credentials

eCom stored credentials can be deleted in one of the following ways depending on the integration type (simple or advanced):

• With simple integration (using redirects), customers can delete stored credentials on the payment page of the Payment service. To make the feature available to Clients, the Partner must obtain permission to delete stored credentials in all banks connected to the Payment service.

  

• With advanced integration (using the API), the Partner can implement unBindCard.do call on their own payment page to allow the Clients to delete stored credentials.

Autopayments with eCom stored credentials

Autopayment is a stored-credential transaction without the client's participation. Therefore, autopayment is a MIT transaction on a regular eCom stored credential, and for such a transaction the tii (transaction initiation indicator) has the type U, see Transaction types.

Autopayments require special permission.

To make an autopayment, pass "tii": "U" in the payment request for stored credentials paymentOrderBinding.do. In such case, CVC is not passed and 3DS is not required after calling the method:

curl --request POST \
--url 'https://api.uat.all2pay.net/v1/paymentOrderBinding.do' \
--header 'Content-Type: application/json' \
--data-raw '{
  "userName":"test_user",
  "password":"test_user_password",
  "bindingId":"fb334d1a-a753-7a80-a1ee-98d94aec9e55",
  "amount":345,
  "clientId":123,
  "mdOrder":"dbcfebe8-109a-11f0-a2c0-ad696c237a94",
  "tii":"U"
}'

Peculiarities:

• Additional permission to transfer tii may be required. Check the necessary permissions with the support service.
• There is an outdated way to make an autopayment by adding "feature": ["AUTO_PAYMENT"] in the order registration request. An example of such a request is not provided, since it is planned to disable the ability to use this feature in the future. It is recommended to use the method with tii as shown above.

Recurring Stored-Credentials Transactions on the Bank's Side

Recurring payments are periodic payments on a fixed schedule for a pre-agreed amount. For example, monthly utility payments or subscription payments. Unlike installment payments, recurring payments do not have a fixed period.

Creating a Recurring Stored Credential

To create a recurring stored credential, the Partner must:

1. In the register.do, registerPreAuth.do, or instantPayment.do method, pass the parameters:

   • recurringFrequency — the minimum number of days between recurring payments.
   • recurringExpiry — the date in the YYYYMMDD format after which further authorizations should not be performed.

   Example of registering an order to create a recurring stored credential:

   curl -X POST 'https://api.uat.all2pay.net/v1/register.do' -H 'Content-Type: application/json' \ \n    --data-raw '{
       "orderNumber": "order_123463",
       "amount": 10000,
       "currency": "643",
       "language": "en",
       "returnUrl": "https://mybestmerchantreturnurl.com/success",
       "userName": "test_user",
       "password": "test_user_password_",
       "clientId": 1010123,
       "jsonParams": {
           "recurringFrequency": 10,
           "recurringExpiry": "20241018"
       }
   }'

2. For a two-request payment scheme, after calling the register.do or registerPreAuth.do method, payment should be made via redirect or API:

   • Via redirect: redirect the client to the payment page using the URL from the formUrl parameter in the request response (similar to creating eCom stored credentials).
     When the client pays for the order in the form, the stored credential will be created regardless of whether the Save card checkbox is checked on the payment page. In this case, the stored credential will be recurring, i.e., it can be used only for recurring debits in the future.
   • Via API: the payment procedure is described in the section Direct payments via API.

Type R stored credentials are created every time the initial payment is made, even if a recurring stored credential with the same card already exists in the bank. Recurring stored credentials of null type are not duplicated.

Payment with Recurring Stored Credential

For payment with a recurring stored credential, the recurrentPayment.do request is used with the bindingId parameter — the stored credential identifier obtained as described in the section ID of the created stored credential.

Features:

• Do not register a new order before payment. The order identifier on the partner's side orderNumber must be unique one for each recurring payment attempt. Specifying an existing orderNumber will result in a payment error.
• The method is only used after performing the initial recurring payment with the additional parameters recurringFrequency and recurringExpiry and creating the recurring stored credential (type "R"). See Creating a Recurring Stored Credential.

Example request:

curl --request POST --url 'https://api.uat.all2pay.net/v1/recurrentPayment.do' \ \n--header 'Content-Type: application/json' \ \n--data-raw '{
    "userName": "test_user",
    "password": "test_user_password",
    "bindingId": "a3f5873b-bda8-7623-b19c-c3f64a87c214",
    "amount": 345,
    "clientId": 1010123,
    "orderNumber": "order_123481"
}'

Payment is made to the same bank where the initiating payment was redirected.

Installment Stored-Credential Transactions on the Bank’s Side

Installment payments are transactions processed at regular fixed intervals according to a payment plan. For example, when a customer pays a bill in small portions monthly. Unlike recurring payments, installment payments are made over a fixed period of time.

Creating an Installment Stored Credential

To create an installment stored credential, the Partner must:

1. In the method register.do, registerPreAuth.do or instantPayment.do, provide the parameters:

   • installments — the maximum number of installment payments.
   • recurringFrequency — the minimum number of days between payments.
   • recurringExpiry — the date in YYYYMMDD format after which no further authorizations should be performed.

   Example of registering an order to create an installment stored credential:

   curl -X POST 'https://api.uat.all2pay.net/v1/register.do' -H 'Content-Type: application/json' \ \n    --data-raw '{
       "orderNumber": "order_123463",
       "amount": 10000,
       "currency": "643",
       "language": "en",
       "returnUrl": "https://mybestmerchantreturnurl.com/success",
       "userName": "test_user",
       "password": "test_user_password_",
       "clientId": 1010123,
       "jsonParams": {
           "recurringFrequency": 15,
           "recurringExpiry": "20241018",
           "installments": "12"
       }
   }'

2. In the two-step payment scheme, after calling the register.do or registerPreAuth.do method, complete the payment via redirect or API:

   • Via redirect: redirect the client to the payment page using the URL in the formUrl parameter in the response (similar to creating an eCom stored credential).
     When the client pays the order in the form, the stored credential will be created regardless of whether the Save Card checkbox is ticked on the payment page. The stored payment data can only be used for installment payments in the future.
   • Via API: for the payment procedure, see the Direct Payments via API section.

The stored credential will be created each time an initiating payment is made, even if an installment stored credential with the same card already exists at the bank.

Payment Using an Installment Stored Credential

When paying using an installment stored credential, the installmentPayment.do request is used with the bindingId parameter — the stored credential identifier obtained as described in the ID of the created stored credential section.

Specifics:

• Do not register a new order before payment. The order identifier on the partner's side orderNumber must be unique one for each installment payment attempt. Specifying an existing orderNumber will result in a payment error.
• The method is only used after making an initial installment payment with the additional parameters installments, recurringFrequency, recurringExpiry, and creating the installment stored credential (type "I"). See Creating an Installment Stored Credential.

Example request:

curl --request POST --url 'https://api.uat.all2pay.net/v1/installmentPayment.do' \
--header 'Content-Type: application/json' \
--data-raw '{
    "userName": "test_user",
    "password": "test_user_password",
    "bindingId": "a3f5873b-bda8-7623-b19c-c3f64a87c214",
    "amount": 345,
    "clientId": 1010123,
    "orderNumber": "order_123481"
}'

The payment is made to the same bank as the initiating payment.

Storing Payment Data on the Partner's Side

Storing payment data on the Partner's side is possible provided PCI DSS compliance is ensured.

The main differences of this storage method:

• Payments with stored credentials are made via paymentOrder.do or instantPayment.do methods. Separate payment methods (i.e. paymentOrderBinding.do, installmentPayment.do, and requrrentPayment.do) are not applicable.
• The Partner must define the tii value according to the transaction type and pass this value in the payment request paymentOrder.do or instantPayment.do. The values ​​used in each case are described in detail below.
• The originalPaymentNetRefNum parameter is required in paymentOrder.do or instantPayment.do for recurring and installment payments. It is returned in the status of the initiating payment. Whether the parameter is mandatory depends on the Partner's settings in the bank.

e-Com Stored Credentials on the Partner side

Creating an eCom Stored Credential on the Partner's Side

To perform an initial payment to create an eCom stored credential on the Partner's side:

1. Follow one of the integration schemes in the section Direct Payments via API.

2. In the paymentOrder.do or instantPayment.do method, submit the initiating payment parameter "tii": "CI"

   Example of an initiating payment for creating a stored credential on the Partner's side:

   curl --request POST --url 'https://api.uat.all2pay.net/v1/paymentOrder.do' \ \n    --header 'Content-Type: application/json' \ \n    --data-raw '{
       "userName": "test_user",
       "password": "test_user_password",
       "mdOrder": "ec52096f-f9c5-42bc-8676-910c4066f1c1",
       "cardholderName": "TEST CARDHOLDER",
       "cvc": "123",
       "month": "12",
       "pan": "4343821200124342",
       "year": "2024",
       "tii": "CI"
   }'

3. During stored credential creation, 3DS check is mandatory. The response to the payment request will include parameters "is3DSVer2": true or acsUrl and paReq. Follow the steps for 3DS Authentication.

Payment with eCom Stored Credentials on the Partner's Side

For subsequent payment with the created stored credential, the Partner should:

1. Follow one of the integration schemes in the section Direct Payments via API.

2. In the paymentOrder.do or instantPayment.do method, provide the tii parameter with the value U or F:

   • F — client-initiated transaction (CIT), for example, if the client chooses to pay with stored credentials on the Partner's payment page.
   • U — merchant-initiated transaction (MIT), if the Partner makes an unscheduled write-off via eCom stored credentials.

   In this method, the Partner must provide stored card data. The paymentOrderBinding.do method cannot be used since there is no payment data stored in the Payment Service or banks for the stored credentials maintained in the Partner's system.

Example request:

curl --request POST --url 'https://api.uat.all2pay.net/v1/paymentOrder.do' \ \n--header 'Content-Type: application/json' \ \n--data-raw '{
    "userName": "test_user",
    "password": "test_user_password",
    "mdOrder": "ec52096f-f9c5-42bc-8676-910c4066f1c1",
    "cardholderName": "TEST CARDHOLDER",
    "cvc": "123",
    "month": "12",
    "pan": "4343821200124342",
    "year": "2024",
    "tii": "U"
}'

Recurring Stored Credentials on the Partner's Side

Creating a Recurring Stored Credential on the Partner's Side

To carry out the initial payment for creating a recurring stored credential on the Partner's side, it is necessary to:

1. Follow one of the integration schemes in the section Direct payments via API.

2. In the paymentOrder.do or instantPayment.do method, pass the parameters of the initial payment:

   • recurringFrequency — the minimum number of days between payments.
   • recurringExpiry — the date in the YYYYMMDD format after which further authorizations should not be performed.
   • "tii": "RI" — transaction type: initial for recurring payments.

   Example of an initial payment to create a credential stored on the Partner's side:

   curl --request POST --url 'https://api.uat.all2pay.net/v1/paymentOrder.do' \ \n    --header 'Content-Type: application/json' \ \n    --data-raw '{
       "userName": "test_user",
       "password": "test_user_password",
       "mdOrder": "ec52096f-f9c5-42bc-8676-910c4066f1c1",
       "cardholderName": "TEST CARDHOLDER",
       "cvc": "123",
       "month": "12",
       "pan": "4343821200124342",
       "year": "2024",
       "tii": "RI",
       "jsonParams": {
           "recurringFrequency": 15,
           "recurringExpiry": "20241018"
       }
   }'

3. Passing 3DS is mandatory when creating a stored credential, therefore the payment request response will include the parameters "is3DSVer2": true or acsUrl and paReq. Follow the steps for 3DS Authentication.

4. Query the order status using getOrderStatusExtended.do to obtain the paymentNetRefNum and date parameters.

Paying with a Recurring Stored Credential from the Partner's Side

For subsequent payments using the created stored credential, the Partner must:

1. Follow one of the integration schemes in the section Direct payments via API.
2. In the paymentOrder.do or instantPayment.do method, pass the parameters:
   • the card data stored by the Partner;
   • tii with the value R;
   • originalPaymentNetRefNum and originalPaymentDate, obtained from the order status in the parameters paymentNetRefNum and date respectively in the initial payment.

Example request:

curl --request POST --url 'https://api.uat.all2pay.net/v1/paymentOrder.do' \ \n--header 'Content-Type: application/json' \ \n--data-raw '{
    "userName": "test_user",
    "password": "test_user_password",
    "mdOrder": "ec52096f-f9c5-42bc-8676-910c4066f1c1",
    "cardholderName": "TEST CARDHOLDER",
    "cvc": "123",
    "month": "12",
    "pan": "4343821200124342",
    "year": "2024",
    "tii": "R",
    "originalPaymentNetRefNum": "10435fbc-8f9c-4f22-aeee-c9daa77741eb",
    "originalPaymentDate": "1726752975535"
}'

Installment Stored Credentials on the Partner’s Side

Creating an Installment Stored Credential on the Partner’s End

To initiate payment for creating an installment stored credential on the Partner’s side:

1. Follow one of the integration schemes described in the Direct Payments via API section.

2. In the method paymentOrder.do or instantPayment.do, provide the parameters for the initiating payment:

   • installments — the maximum number of installment payments.
   • recurringFrequency — the minimum number of days between payments.
   • recurringExpiry — the date in YYYYMMDD format after which no further authorizations should take place.
   • "tii": "II" — transaction type: initiating for installment payments.

   Example of an initiating payment to create a stored credential on the Partner’s side:

   curl --request POST --url 'https://api.uat.all2pay.net/v1/paymentOrder.do' \
   --header 'Content-Type: application/json' \
   --data-raw '{
       "userName": "test_user",
       "password": "test_user_password",
       "mdOrder": "ec52096f-f9c5-42bc-8676-910c4066f1c1",
       "cardholderName": "TEST CARDHOLDER",
       "cvc": "123",
       "month": "12",
       "pan": "4343821200124342",
       "year": "2024",
       "tii": "II",
       "jsonParams": {
           "recurringFrequency": 15,
           "recurringExpiry": "20241018",
           "installments": "12"
       }
   }'

3. During the creation of the stored credential, 3DS completion is mandatory; therefore, the response to the payment request will contain the parameters "is3DSVer2": true or acsUrl and paReq. Follow the steps for 3DS Authentication.

4. Request the order status via getOrderStatusExtended.do to obtain the paymentNetRefNum and date parameters.

Payment Using an Installment Stored Credential on the Partner’s End

To perform subsequent payments using the created stored credential, the Partner must:

1. Follow one of the integration schemes described in the Direct Payments via API section.
2. In the method paymentOrder.do or instantPayment.do, provide the parameters:
   • the card data from the credentials stored by the Partner;
   • tii with the value I;
   • originalPaymentNetRefNum and originalPaymentDate, obtained in the order status for the initiating payment in the parameters paymentNetRefNum and date, respectively.

Example request:

curl --request POST --url 'https://api.uat.all2pay.net/v1/paymentOrder.do' \
--header 'Content-Type: application/json' \
--data-raw '{
    "userName": "test_user",
    "password": "test_user_password",
    "mdOrder": "ec52096f-f9c5-42bc-8676-910c4066f1c1",
    "cardholderName": "TEST CARDHOLDER",
    "cvc": "123",
    "month": "12",
    "pan": "4343821200124342",
    "year": "2024",
    "tii": "I",
    "originalPaymentNetRefNum": "10435fbc-8f9c-4f22-aeee-c9daa77741eb",
    "originalPaymentDate": "1726752975535"
}'