Generation of seToken

What is seToken

seToken (Self Encrypted Token) is a cryptogram used for the secure transmission of payment data. It can be utilized in the following requests when card data is collected on the Partner's side:

Below is the description of how to create a seToken and send it in a payment request. Alternatively, you can use Mobile SDK Core for token generation.

Format of seToken before encryption

Before encryption, seToken is a string that includes the parameters listed below, separated by the "/" symbol.

Parameters included in seToken

The table below lists the parameters that can be used in the seToken string. These parameters must be included in the string in strict sequence according to the table.

Parameter	Mandatory	Description
timestamp	yes	Request date in ISO 8601:2004 standard format YYYY-MM-DDThh:mm:ss±hh:mm. It must not differ by more than half an hour from the date/time of receiving the request in the RBS.
UUID	yes	Identifier in UUID standard, generated as described here.
PAN	yes	Debit card number
CVV	no	Card verification code. This parameter is mandatory if the Partner does not have permission for payment without CVC confirmation.
EXPDATE	no	Debit card expiration date (in the format YYYYMM, where YYYY - year, MM - month)
mdOrder	yes	Order identifier that needs to be paid using the cryptogram

If a parameter is not transferred, its place in the string is preserved but left empty. Valid sets of data are:

timestamp/UUID/PAN/CVV/EXPDATE/mdOrder
timestamp/UUID/PAN//EXPDATE/mdOrder
timestamp/UUID/PAN///mdOrder

Example of a generated string:

2024-09-03T10:10:24+03:00/13a4713c-bf5e-47d5-b986-74887875b02e/2200650800006500/123/202412/4e8c4947-13c3-42d6-9fbd-ca8ba44991bf

where:

corresponding time is 2024-09-03T10:10:24+03:00;
generated unique UUID;
PAN — 2200650800006500;
CVV — 123;
card expiration date is December 2024;
order identifier.

Algorithm for creating a payment request

Send a request for the key

The payment service AntiDDOS Router supports two types of keys:
- Key length of 4096 bits for the algorithm RSA/NONE/OAEPWithSHA512AndMGF1Padding. To obtain this key, call the method https://api.uat.all2pay.net/v1/se/keys2.do. This type of key is recommended.
- Key length of 2048 bits for the encryption algorithm RSA/None/PKCS1Padding. To obtain this key, call https://api.uat.all2pay.net/v1/se/keys.do.
Keys are returned in the following format:
```
{
"keys": [
    {
        "keyValue": "{Public key in PEM format}",
        "protocolVersion": "RSA-4096",
        "keyExpiration": 1741006920
     }
]   
}
```
Both methods may return multiple keys. It is advisable to use the most recent key with the latest expiration date keyExpiration. You can cache the public keys of the Payment Service on your side for a time not exceeding the key's expiration period.

Keys for test and production environments differ.
Register the order
- Order registration
- Order registration with pre-authorization
Generate the string to be encrypted

Example of a string:

2024-09-03T10:10:24+03:00/13a4713c-bf5e-47d5-b986-74887875b02e/2200650800006500/123/202412/4e8c4947-13c3-42d6-9fbd-ca8ba44991bf
Encrypt the resulting string

The resulting string must be encrypted with the public key of the Payment Service:
- When using the RSA-2048 key, the encryption is performed with the RSA/None/PKCS1Padding algorithm
- When using the RSA-4096 key, the encryption is performed with the RSA/None/OAEPWithSHA-512AndMGF1Padding algorithm, with the hash SHA-512 used for MGF padding.
Example encryption result:

LeOm7yE1wvw8/r0aBv5nOMlrodhPFIB8POu9YPt60CTQL3aS6AiBCNuveEkUzRtxO5JHjE4H50MC6S6oY7/JqT3QJFhCRxMBRCaaxcczG3MTU8NakxIPYA496zBUr9pCspQ/F6hyockEPIdst0WD2HgB25zZFpjUvBDExGtfINqT0+mcsFGBdf8knj5JMzKieakk/w8ahzHmXVDx2zNfNT4TBdgKUmYNeiYe+mPHmVzQo37OLBvZQ5tEl3gAZHSzBUyaKcCZJJcnpjWWvY+A8hCeMLjttX0Y+RhOmdduYQ5SvrDO3HJcZi2EVJISD/ZF8Y4XAs2KQwORWyOzngd6RA==
Send a payment request with seToken

See an example of a payment request with seToken here.
If 3DS V2 is required, send a second payment request with the same seToken

When performing a 3DS V2 check, it is necessary to send the payment request twice — see Passing 3DS. In the repeated payment request (paymentOrder.do or instantPayment.do), use the same seToken as in the first request. Generating a new token with a new timestamp is not required.