Page History
...
Name | Manda- | Accepted values | Default value | Description | ||
Merchant_ID | Yes | Number | Merchant identification number in IPS Assist | |||
Login | Yes | String | Service Login | |||
Password | Yes | String | Password | |||
OrderNumber | Yes/No | 128 symbols | Order number (order identification on the merchant side) | |||
OrderAmount | Yes | Number, 15 digits, two digits after the delimiter (delimiter '.') | Payment amount (ex.: 10.34) | |||
OrderCurrency | No | 3 symbols | Default currency of enterprise or merchant | Order currency code (for OrderAmount value) Ex.: RUB, USD, EUR and so on. | ||
OrderComment | No | 4000 symbols | Order comment | |||
Delay | No | 0 - one stage payment, | 0 | Flag for selection of one or two payment stages
| ||
Language | No | RU - Russian | Enterprise or merchant language | Language of payment pages | ||
ClientIP | No/Yes | IP-address of customer. IP-address of customer. The parameter is mandatory for the 3-D Secure protocol version 2. | ||||
Cardtype | No | 1 - VISA | Card type | |||
Cardnumber | Yes | Card number | ||||
Cardholder | No* | 70 letters (no digits). Space as delimiter | Card-holder | |||
Expiremonth | Yes | 1-12 | Card expiration month | |||
Expireyear | Yes | Year in YYYY format | Card expiration year | |||
Cvc2 | Yes | CVC2 code | ||||
Lastname | No* | 70 letters (no digits) | Customer second name | |||
Firstname | No* | 70 letters (no digits) | Customer first name | |||
Middlename | No | 70 letters (no digits) | Customer middle name | |||
No* | 128 symbols | E-mail of customer | ||||
Address | No | 256 symbols | Customer address | |||
HomePhone | No | 64 symbols | Customer home phone | |||
WorkPhone | No | 20 symbols | Customer work phone | |||
MobilePhone | No | 20 symbols | Customer mobile phone | |||
Country | No | 3 symbols | Customer's country code | |||
State | No | 3 symbols | Customer's region code | |||
City | No | 70 symbols | Customer's city | |||
Zip | No | 25 symbols | Customer's postal index | |||
isConvert | No | 0 - don't convert to the base currency 1 - don't convert to the base currency if possible 2 - always convert to the base currency | 1 | Currency conversion indicator | ||
Format | No | 1 - CSV | 1 | Results format. If the request is sent in SOAP or in JSON format, then the response will also be in SOAP or in JSON respectively, in other cases, in accordance with the passed format value. | ||
Signature | No | String | The string is joined according to determined rules. Then the MD5 hash prepared from this string. Hash is signed by private RSA key of the merchant. Key length - 1024. Received bit sequence is a signature. Signature is transferred BASE64 coded string.
| |||
RecurringIndicator | No | 1 - recurring payment 0 - standard payment | 0 | Recurring payment indicator
| ||
RecurringMinAmount | No/Yes | Number, 15 digits, two digits after the delimiter (delimiter '.') | Minimum payment amount for recurring payments . Mandatory when RecurringIndicator = 1.
| |||
RecurringMaxAmount | No/Yes | Number, 15 digits, two digits after the delimiter (delimiter '.') | Maximum payment amount for recurring payments . Mandatory when RecurringIndicator = 1
| |||
RecurringPeriod | No/Yes | 3 digits number | Recurring interval in days . Mandatory when RecurringIndicator = 1.
| |||
RecurringMaxDate | No/Yes | Date in string representation DD.MM.YYYY | Finish date of recurring payments . Mandatory when RecurringIndicator = 1.
| |||
CustomerNumber | No | 32 symbols | Merchant's internal customer identification
| |||
SaveCard | No | 1 - the card is stored to this customer number; 0 - the card is not stored. | 0 | This parameter permits to store the card to this client number for subsequent payments, if the current payment is successful. If this card for this client number already has been saved before, the parameter is ignored. | ||
| Disable3DS | No | 0 - perform 3D-Secure authorization according to the merchant settings; 1 - fulfill payment without 3-D Secure. | 0 | Flag of disabling 3-D Secure. The use of this operating mode is possible in agreement with Assist. To configure it, you need to contact the support service (support@belassist.by). When using this parameter, it must also be added to the order signature, which is built according to determined rules . |
...
The additional fields are also added in the silentpay response packet. These fields allow the merchant to provide additional payer authentication using 3-D Secure technologies (VISA cards) and Mastercard SecureCode (Mastercard catds).Mastercard catds).
For cards of international payment systems VISA and Mastercard in most cases version 2 of the 3D-Secure protocol is used by Currently, for additional authentication of the customer, the most issuing banks operate according to the 3-D Secure protocol version 1 for all types of cards.For a more secure authentication process, issuing banks and payment systems are switching to a new version 2 of protocol for all types of cards (VISA, Mastercard). To support a new generation protocol, a merchant has to make changes to the customer authentication process.same version of the protocol is also used for UPI cards. For cards of the BELKART payment system, authentication is carried out according to version 1 of the protocol.
To start the order payment, the merchant sends an authorization request to the IPS Assist server. The following data about the customer device and browser must be added to the usual request parameters, if this has not been done before for operating with the SOFI. This data is required in the new 3-D Secure protocol version 2.
...
- Check the version of the 3D-Secure protocol in response to an authorization request to the Assist service. For version 1, support the workflow described above.
- For version 2, create a hidden iFrame on the payment page (for a detailed parameters description see below) and send 3DSMethod request (if available) to the issuing bank ACS.
- To continue authentication, call the ws3dsecver2 get3dsecver2 web service with additional 3D-Secure parameters. If authentication occurs without additional interaction with the customer (Frictionless Flow), then Assist will receive its result and send the authorization transaction to the processing. The enterprise will receive in response a full payment result, which also contains the result of authorization in processing. If additional authentication of the customer is necessary, then the IPS Assist will return additional fields for verification (Challenge Flow) in response to the request.
- If there are additional fields in the response that indicate the need for additional verification, the enterprise creates an iFrame on the payment page, which implements the display of the ACS page of the issuing bank to enter a one-time password. Customer completes authentication.
- IPS Assist will receive the result of the verification to the server on its side. In case of successful verification, a payment transaction will be processed. If the verification fails, the operation will fail.
- To find out the final result of payment for an order, the enterprise must use one of the methods for obtaining an authorization result.
...