Creation of the payment form
The merchant server receives a payment request from the mobile application and must transmit it to the payment gateway.
To do this, the merchant website will generate an HTML payment form that it will post to the payment gateway.
The integrity of shared data is guaranteed by the exchange of alphanumeric signatures between the payment gateway and the merchant server.
The merchant server will transmit the alphanumeric signature in the payment form (see chapter Computing the signature).
- Use all the fields of the table below to build your payment request.
Field name Description Format Value vads_site_id Shop ID n8 E.g.: 12345678 vads_currency Numeric currency code to be used for the payment, in compliance with the ISO 4217 standard (numeric code). n3 E.g.: 978 for euro (EUR) vads_amount Payment amount in the smallest currency unit (cents for euro). n..12 E.g.: 3000 for 30,00 EUR vads_cust_email Buyer’s e-mail address ans..150 E.g.: abc@example.com vads_payment_cards Card type. String E.g.: VISA (See the Implementation guide - Hosted Payment Form to view the list of possible values).
vads_order_id Order ID ans..64 E.g.: 2-XQ001 vads_version Version of the exchange protocol with the payment gateway enum V2 vads_theme_config Allows to improve performance by disabling some elements of the payment page, such as the language selector, the logos at the bottom of the page, etc. map SIMPLIFIED_DISPLAY=true
vads_trans_date Date and time of the payment form in UTC format n14 Respect the YYYYMMDDHHMMSS format
E.g.: 20200101130025vads_trans_id Transaction number an6 E.g.: xrT15p vads_payment_config Payment type enum SINGLE for immediate payment MULTI for installment payment
vads_page_action Action to perform enum PAYMENT vads_ctx_mode Defines the mode of interaction with the payment gateway. enum TEST or PRODUCTION vads_action_mode Acquisition mode for payment method data enum INTERACTIVE signature Signature guaranteeing the requests integrity exchanged between the merchant website and the payment gateway. Its value calculation is described here: Computing the signature. ans44 E.g.: NrHSHyBBBc+TtcauudspNHQ5cYcy4tS4IjvdC0ztFe8=
- Use the fields below to manage the return to the mobile application at the end of the payment.
A payment can result in 4 different states:
Payment accepted,
Payment declined,
Payment error,
Payment abandoned by the buyer.
You must associate a URL to each status:
Field name Description Format Value vads_url_success URL where the buyer will be redirected in case of a successful transaction.
ans..1024 E.g.: http://webview.success
vads_url_refused URL where the buyer will be redirected in case of a declined transaction.
ans..1024 E.g.: http://webview.refused
vads_url_cancel URL where the buyer will be redirected in case of an abandoned or expired transaction (timeout).
ans..1024 E.g.: http://webview.cancel
vads_url_error URL where the buyer will be redirected in case of an error.
ans..1024 E.g.: http://webview.error
- Use the fields below to configure the time of redirection to the mobile application at the end of the payment:
Field name Description Format vads_redirect_success_timeout Defines the delay before the redirection that follows an accepted payment.
This delay is presented in seconds and must be between 0 and 300 sec.Set this field to "0" to not display the payment ticket and to automatically redirect the buyer to the mobile application.
n..3 vads_redirect_error_timeout Defines the delay before the redirection that follows a declined payment.
This delay is presented in seconds and must be between 0 and 300 sec.Set this field to "0" to not display the payment rejection page and to automatically redirect the buyer to the mobile application.
n..3 - Add other optional fields according to your needs (see the following subsections).