Parameters for opening payment form
This article describes parameters used to open Payment Page, including basic information about them and links to related articles, which contain descriptions of the parameters' functionality and set out possible scenarios for their use.
Parameters marked in this list as required must be included in all Payment Page calls intended to process payments. In the Card Tokenize mode, the following parameters are not required: payment_amount
, payment_currency
, payment_id
.
Parameters marked in this list as optional can be used as additional parameters for specific projects and payment methods. Moreover, the inclusion of some parameters is recommended for specific use casesin order to avoid the customer being subjected to the 3‑D Secure authentication procedure (i.e., undergo authentication via the frictionless flow instead of the challenge flow; details) and having to provide additional payment information, as well as for other improvements to custom scenarios and the general functionality of the payment form.
If you have any additional questions about whether specific parameters are required or recommended for different individual use cases, consult the existing documentation and the ecommpay technical support specialists.
Parameter | Description |
---|---|
|
Payment instrument token. Consists of an identifier obtained for a specific payment instrument from the payment platform when data for that instrument is saved. Can be used to perform payments using that saved data (i.e., when making a purchase). Example: |
|
Booking itineraryBooking itinerary information. Consists of a string obtained by encoding a JSON object using the Base64 encoding scheme. Can be used to pay for services of companies in the travel industry, making the payments more secure and allowing for more competitive payment processing rates (see Using addendum with itinerary data). Subject to regulations of the Mastercard and Visa global card schemes. { "lodging": { "customer_service_toll_free_number": "18005553535", // Customer service phone "guest_name": "John Smith", // Guest name "check_in_date": "10-12-2019", // Checkin date "check_out_date": "22-12-2019", // Checkout date "folio_number": "56265655ABC", // Booking ID "fire_safety_act_indicator": true, // Fire safety compliance indicator "room": { // Object with the room details "rate": 12, // Daily room rate "number_of_nights": "12" // Booked nights number }, "charges": { // Object with the charges details "transportation": 1200, // Transportation charges "internet_access": 4500 // Internet access charges } } }
|
|
The postal code of the customer to be used in the Address Verification ServiceAVS check. Example: |
|
The address of the customer to be used in the Address Verification ServiceAVS check. Consists of a house number and a street name. Example: |
|
The base URL used to open the payment form. Must be specified when a root address different from the default one (https://paymentpage.ecommpay.com) has been approved by the ecommpay account manager, in cases where the address needs to be provided explicitly. Example: |
|
The date and time in the specified timezone until which the customer is able to use the payment form to confirm their targeted actionafter which the customer can no longer use the payment form (see this article). Should be specified in the following format: Example: |
|
The house number (including any additional parts of the address such as building indicators and apartment numbers) and the name of the street in street name of the customer's billing address. When the parameter is passed for card payments, data contained in this parameter may serve to improve the probability of a successful 3‑D Secure authentication without any further input from the customer (i.e., authentication via the frictionless flow instead of the challenge flow; details). Example: |
|
The name of the city in the customer's billing address. When the parameter is passed for card payments, data contained in this parameter may serve to improve the probability of a successful 3‑D Secure authentication without any further input from the customer (i.e., authentication via the frictionless flow instead of the challenge flow; details). Example: |
|
The country code in the customer's billing address in the ISO 3166-1 alpha-2 format. Specified in the ISO 3166-1 alpha-2 format. When the parameter is passed for card payments, data contained in this parameter may serve to improve the probability of a successful 3‑D Secure authentication without any further input from the customer (i.e., authentication via the frictionless flow instead of the challenge flow; details). Example: |
|
The postal code in the customer's billing address. When the parameter is passed for card payments, data contained in this parameter may serve to improve the probability of a successful 3‑D Secure authentication without any further input from the customer (i.e., authentication via the frictionless flow instead of the challenge flow; details). Example: |
|
The name of the region (i.e., state, province, or other administrative division type) in the customer's billing address. When the parameter is passed for card payments, data contained in this parameter may serve to improve the probability of a successful 3‑D Secure authentication without any further input from the customer (i.e., authentication via the frictionless flow instead of the challenge flow; details). Example: |
|
The recipient's country subdivision code (state, province, region, or territory). The value of this parameter is the second element of a code for a subdivision (in ISO 3166-2), without the two-letter country code and the hyphen-minus used as a separator. This parameter should be specified in requests where the The internal region code in the customer's billing address. Consists of the second part of the ISO 3166-2 international territory code (without the two-letter country code or the separating hyphen) and should be specified in requests where the Example: |
|
Booking information tracked by the web service (see this article). Consists of a string obtained by encoding a JSON object using the Base64 encoding scheme. Can be used to record and track relevant data about payments rendered for services by various organisations (see this article). "booking_info": { "firstname": "William", "surname": "Herschel", "email": "rsfellow@mail.com", "start_date": "12-08-2026", "end_date": "13-08-2026", "description": "Sideris music festival full pass", "total": 200000, "pax": 4, "reference": "musicfestlink", "id": "83" }
|
|
The first and last name of the payment card holder. Data specified in this parameter can be used to fill in the corresponding fields on the payment form in advance—this data can then still be edited by the customer—and should be spelled as specified on the card and adhere to the rules for specifying names (see this article). Example: |
|
Indicator that specifies whether a purchase made using a payment card is processed in one or two steps. Indicator that specifies the type of purchase made using a payment card with the 4th generation of Payment Page or earlier: Should be specified in cases where the intended payment type is different from the one specified by default (with regard to the number of steps). Can have one of the following values:
Should be specified in cases where the intended payment type is different from the one specified by default. Can be used for the 4th generation of Payment Page or earlier. Example: |
|
Indicator that specifies the action to be taken if the customer clicks outside of the borders of a payment form opened in a modal window.: Should be specified for calls that make use of a modal window. Can have one of the following values:
If the Example: |
|
Indicator for an additional CSS class to wrap the payment form inside of a modal window. Should be specified for calls that make use of a modal window. Example: |
|
The name of the street and the house number (including any additional parts of the address such as building indicators and apartment numbers) in the customer's address, separated by a comma. The length of the string cannot be more than 255 characters. Passing this information, along with other information about the customer, may help avoid having to provide additional information about the payment and simplify user scenarios (see this article). Example: |
|
Information about the customer's account and contact details obtained by the web service (see this article). Consists of a string obtained by encoding a JSON object using the Base64 encoding scheme. { "customer":{ "address_match":"Y", "home_phone":"442055526608", "work_phone":"442055537709", "account":{ "additional":"gamer12345", "age_indicator":"01", "date":"01-10-2022", "change_indicator":"01", "change_date":"01-10-2022", "pass_change_indicator":"01", "pass_change_date":"01-10-2022", "purchase_number":12, "provision_attempts":16, "activity_day":22, "activity_year":222, "payment_age_indicator":"01", "payment_age":"01-10-2022", "suspicious_activity":"01", "auth_method":"01", "auth_time":"01-10-202213:12", "auth_data":"login_0102" } } }
|
|
The identifier assigned to the customer's account by the payment system. May be required when using specific payment methods (e.g., Neteller and OVO Wallet). Depending on the particular method, may consist of an e-wallet identifier, an email address, a phone number, or a different kind of identifier. Example: |
|
The name of the customer's birthplace (e.g., town, city, or other settlement type). The length of the string cannot be more than 255 characters. Passing this information, along with other information about the customer, may help avoid having to provide additional information about the payment and simplify user scenarios (see this article). Example: |
|
The name of the place of residence (e.g., town, city, or other settlement type) in the customer's address. The length of the string cannot be more than 255 characters. Passing this information, along with other information about the customer, may help avoid having to provide additional information about the payment and simplify user scenarios (see this article). Example: |
|
The country code in the customer's address (in ISO 3166-1 alpha-2 format). Specified in ISO 3166-1 alpha-2 format. Passing this information, along with other information about the customer, may help avoid having to provide additional information about the payment and simplify user scenarios (see this article). Example: |
|
The date of birth of the customer in Consists of a string specified in Example: |
|
The email address of the customer. The length of the string cannot be more than 255 characters. The string consists of a local-part and a domain name, separated by the "@" symbol. Required for purchases made using a payment card if the Example: |
|
The first name of the customer. The length of the string cannot be more than 255 characters. Passing this information, along with other information about the customer, may help avoid having to provide additional information about the payment and simplify user scenarios (see this article). Example: |
|
The identifier assigned to the customer within the scope of the project (specified in Each web service account should be linked to only one identifier and vice versa. This requirement is intended to address various risks and fraudulent operations. Example: |
|
The last name of the customer. The length of the string cannot be more than 255 characters. Passing this information, along with other information about the customer, may help avoid having to provide additional information about the payment and simplify user scenarios (see this article). Example: |
|
The middle, second, or patronymic name of the customer. The length of the string cannot be more than 255 characters. Passing this information, along with other information about the customer, may help avoid having to provide additional information about the payment and simplify user scenarios (see this article). Example: |
|
Information about the customer's most recent authentication via the 3‑D Secure protocol (see this article). Consists of a string obtained by encoding a JSON object using the Base64 encoding scheme. When passed for card purchases, data contained in this parameter may serve to improve the probability of a successful 3‑D Secure authentication without any further input from the customer (i.e., authentication via the frictionless flow instead of the challenge flow; details). { "customer":{ "mpi_result":{ "acs_operation_id":"00000000-0005-5a5a-8000-016d3ea31d54", "authentication_flow":"01", "authentication_timestamp":"202210111050" } } }
|
|
The phone number of the customer. Generally, should include the country code and contain between 4 and 24 digits. Generally, should include the country code; however, some cases do not require a country code to be specified. Should contain between four and 24 digits. If a particular project and payment method allow for the inclusion of punctuation marks and special characters in the phone number, the parameter can contain such characters in those cases; this is usually specially arranged beforehand. Required for purchases made using a payment card if the Example: |
|
The customer's purchase confirmation code. Some payment methods may require this parameter (depending on the methods themselves). Example: |
|
Information about the delivery of a product or a service rendered to the customer (see this article). Consists of a string obtained by encoding a JSON object using the Base64 encoding scheme. When passed for card purchases, data contained in this parameter may serve to improve the probability of a successful 3‑D Secure authentication without any further input from the customer (i.e., authentication via the frictionless flow instead of the challenge flow; details). { "customer":{ "shipping":{ "type":"01", "delivery_time":"01", "delivery_email":"test@gmail.com", "address_usage_indicator":"01", "address_usage":"01-10-2022", "city":"London", "country":"GB", "address":"Blackheath Ave", "postal":"SE10 8XJ", "region_code":"LND", "name_indicator":"01" } } }
|
|
The last four digits of the social security number of a US citizen. Passing this information, along with other information about the customer, may help avoid having to provide additional information about the payment and simplify user scenarios (see this article). Example: |
|
The name of the region (state, province, or other administrative subdivision type) of in the customer's address. The length of the string cannot be more than 255 characters. Passing this information, along with other information about the customer, may help avoid having to provide additional information about the payment and simplify user scenarios (see this article). Example: |
|
The name of the street in the customer's address. The length of the string cannot be more than 255 characters. Passing this information, along with other information about the customer, may help avoid having to provide additional information about the payment and simplify user scenarios (see this article). Example: |
|
The postal or zip code in the customer's address. Passing this information, along with other information about the customer, may help avoid having to provide additional information about the payment and simplify user scenarios (see this article). Example: |
|
The number of the account designated to receive funds as part of debt settlement purchases (see this article). This parameter is required for debt settlement purchases (see this article). The length of the string cannot be more than ten characters. Only Latin-script letters and digits are allowed. Example: |
|
Indicator specifying whether a third-party web service that the customer is redirected to is opened in a new tab or not (see this article).: May be required for specific payment methods and can have one of the following values:
If the Example: |
|
The code of the payment method that should be preselected for the payment (see this article); should correspond to the code for the relevant method from the payment method code list. Can have values specified in the payment method code list. Example: |
|
The code of the payment method group that should be preselected for the payment (see this article). If this parameter is passed, only those payment methods that are part of the corresponding method group and are supported within the project will be available to the customer. However, if this parameter is passed together with the Currently, this parameter can be used to preselect the Open Banking method group when you work with the 4th generation Payment Page—to do so, specify When passed together with the Example: |
|
The code of the payment card brand that should be preselected for the payment (see this aticle); should correspond to the code for the relevant card brand from the payment card code list. Can have values specified in the payment card code list. Example: |
|
A single code or a list of codes for payment methods that should be excluded from the payment form for the payment (details). If a list of codes is specified, they should be separated by commas. Can have values specified in the payment method code list. Codes of payment methods that should be excluded from the payment form for the payment (details); codes from the payment method code list should be separated by commas. Example: |
|
The identifier of the document serving as a proof of identity for the customer. May be required for specific payment methods and can consist of a personal identity number (e.g., Trustly), a taxpayer number (e.g., PIX), or other similar identifiers. Example: |
|
An identifier for the interface of the payment platform. Using this parameter requires case-by-case coordination with ecommpay. Example: |
|
The code of the language in which the payment form should be displayed (see this article). Can consist of a two-letter ISO 639-1 alpha-2 code (see Language codes) or a code in a different format when this has been arranged prior. Example: |
|
URL for handling request callbacks. This parameter should be passed when callbacks for a request need to be sent to an address that is different from that specified by default (for information about callbacks and how to use them, see this article). Example: |
|
Additional information that needs to be tracked by the web service (see this article). The data that is passed in this parameter can vary. However, what data set is passed in this parameter should be communicated to the ecommpay specialists and configured beforehand to ensure the data is processed and displayed correctly in callbacks and payment information tabs (see this article). In specific cases can contain a JSON object; then, the "merchant_data": "{"items":[{"sku":"GM12-CC", "description":"10 Copper Coins","count":1}, {"sku":"GM12-GC","description":"Golden Coin", "count":2}],"total_count":3,"user_id":"122"}" "merchant_data": "{\"items\":[{\"sku\":\"GM12-CC\", \"description\":\"10 Copper Coins\",\"count\":1}, {\"sku\":\"GM12-GC\",\"description\":\"Golden Coin\", \"count\":2}],\"total_count\":3,\"user_id\":\"122\"}" |
|
Indicator that specifies the availability options for the final redirection of the customer to the web service when a purchase is declined. (see this article): Can have one of the following values:
For more information about managing options for redirecting the customer back to the web service, see this article. Example: |
|
Indicator that specifies the mode for the final redirection of the customer to the web service when a purchase is declined. (see this article): Can have one of the following values:
For more information about managing options for redirecting the customer back to the web service, see this article. Example: |
|
URL for final redirection to the web service by customer decision when a purchase is declined (see this article). For more information about managing options for redirecting the customer back to the web service, see this article. Example: |
|
Indicator that specifies the availability options for the preliminary redirection of the customer to the web service from the payment form. (see this article): Can have one of the following values:
For more information about managing options for redirecting the customer back to the web service, see this article. Example: |
|
Indicator that specifies the mode for the preliminary redirection of the customer to the web service from the payment form. (see this article): Can have one of the following values:
For more information about managing options for redirecting the customer back to the web service, see this article. Example: |
|
URL for preliminary redirection to the web service from the payment form (see this article). For more information about managing options for redirecting the customer back to the web service, see this article. Example: |
|
Indicator that specifies the availability options for the final redirection of the customer to the web service when the purchase is completed. (see this article): Can have one of the following values:
For more information about managing options for redirecting the customer back to the web service, see this article. Example: |
|
Indicator that specifies the mode for the final redirection of the customer to the web service when the purchase is completed. (see this article): Can have one of the following values:
For more information about managing options for redirecting the customer back to the web service, see this article. Example: |
|
URL for final redirection to the web service by customer decision when the purchase is completed (see this article). For more information about managing options for redirecting the customer back to the web service, see this article. Example: |
|
Indicator that specifies the Payment Page operation mode.: Can have one of the following values:
Example: |
|
Type of order for carrying out a Mail Order/Telephone Order an MO/TO purchase (involving the owner of the payment card providing its details over phone, mail, fax, or email):
Example: |
|
Indicator that specifies whether a the type of purchase made using a payment card is processed in one or two steps. with the 5th generation of Payment Page: Should be specified in cases where the intended payment type is different from the one specified by default (with regard to the number of steps). Can have one of the following values:
Can be used for the 5th generation of Payment Page. Should be specified in cases where the intended payment type is different from the one specified by default. Example: |
|
The amount of the payment in the smallest currency unit. Specified in the smallest currency unit without a decimal separator. Required for all Payment Page modes except Card Tokenize. Not required for Card Tokenize mode. Example: |
|
Three-letter code of the payment currency. The payment currency code (in the ISO-4217 alpha-3 format, according to the currency codes reference). Specified in the ISO-4217 alpha-3 format, according to the currency codes reference. Required for all Payment Page modes except Card Tokenize. Example: |
|
A short description for the payment, at most 255 characters longintended to be displayed to the customer, as well as being used by the web service for tracking purposes. The length of the string cannot be more than 255 characters. Can be displayed to the customer on the information page, or via system notifications and the Dashboard interface. Example: |
|
Additional relevant information pertaining to the payment. May be required for specific payment methods (e.g., Trustly) and in other individual cases. Generally, where and how this parameter is used, as well as the format of any data contained therein should be decided upon during the integration of the web service, or when implementing additional payment methods or capabilities in advance. |
|
The payment identifier assigned within the project; at most 255 characters long, case-insensitive. Must be assigned by the web service. Should consist of a string no longer than 255 characters, be case-insensitive, and correspond one-to-one with the relevant payment within that project. Required for all Payment Page modes except Card Tokenize. Example: |
|
Additional information about a purchase made for goods or services by a customer and about which 3‑D Secure authentication method is preferred by the merchant (see this article). Consists of a string obtained by encoding a JSON object using the Base64 encoding scheme. When the parameter is passed for card payments, data contained in this parameter may serve to improve the probability of a successful 3‑D Secure authentication without any further input from the customer (i.e., authentication via the frictionless flow instead of the challenge flow; details). { "payment":{ "reorder":"01", "preorder_purchase":"01", "preorder_date":"11-10-2022", "challenge_indicator":"01", "challenge_window":"01", "gift_card":{ "amount":12345, "currency":"USD", "count":1 } } }
|
|
Additional information relevant for specific payment methods and third-party services. Can be used to manage individual methods, including Open Banking methods, in order to send additional information about the customer and the payment, manage the page size of third-party web services that the customer is redirected to, and for other possible reasons, depending on the specific payment methods being used. Example: |
|
Identifier of the project intended to manage the interactions of the web service with the payment platform. This identifier is, assigned by ecommpay during the integration (details). Example: |
|
Information about line items in an order (see this article). Can be used to generate a document to be sent to the customer (see this article). Consists of a string obtained by encoding a JSON object using the Base64 encoding scheme. { "receipt_data":{ "positions":[ { "quantity":3, "amount":10000, "tax":18, "tax_amount":1800, "description":"Design frame" } ], "total_tax_amount":1800, "common_tax":18 } }
|
|
The name of the street and the house number (including any additional parts of the address such as building indicators and apartment numbers) in the address of the payment recipient, at most 99 characters long. The length of the string cannot be more than 99 characters. Example: |
|
The first and last names of the holder of the payment card used to receive the payment, at most 255 characters long. Should be spelled as specified on the card and adhere to the rules for specifying names (see this article). The length of the string cannot be more than 255 characters. Example: |
|
The name of the place of residence (e.g., town, city, or other settlement type) in the address of the payment recipient, at most 25 characters long. The length of the string cannot be more than 25 characters. Example: |
|
The country code of the place of residence of the payment recipient (in the ISO 3166-1 alpha-2 format). Specified in the ISO 3166-1 alpha-2 format. Example: |
|
The name of the payment recipient, at most 255 characters. The length of the string cannot be more than 255 characters. Example: |
|
The last name of the payment recipient, at most 255 characters. The length of the string cannot be more than 255 characters. Example: |
|
The number of the payment card used to receive the payment. Specified as is, without masked characters, spaces, or other separators. Example: |
|
The local code of the region (state, province, or other administrative subdivision type) of the payment recipient's address. The value of this parameter is the second element of a code for a subdivision (in ISO 3166-2), without the two-letter country code and the hyphen-minus used as a separator. Should be specifiedSpecified when the Example: |
|
The identifier of the digital wallet used by the payment recipient, at most 64 characters. The length of the string cannot be more than 64 characters. Specified as is, without masked characters, spaces, or other separators. Example: |
|
The first and last names of the owner of the digital wallet used by the payment recipient, at most 255 characters in total. Should be spelled the same way as in the payment system and be at most 255 characters long in total. Example: |
|
Information about the COF purchase being registered (details). If the ecommpay JavaScript library is used, can be passed as a JSON object, otherwise should be specified as a URL obtained by encoding the source JSON object. { "register": true, "type": "U" } %7B%22register%22%3Atrue%2C%22type%22%3A%22U%22%7D%2C |
|
Indicator specifying whether a COF purchase should be registered, using the information passed in the Can have one of the following values:
If the Example: |
|
Indicator specifying whether the payment form should be opened on a new HTML page regardless of the type of device being used (see this article).: Can have one of the following values:
If the Example: |
|
Indicator that specifies the mode for the final redirection of the customer to the web service when the purchase is declined (see this article):. Can have one of the following values:
For more information about managing options for redirecting the customer back to the web service, see this article. Example: |
|
URL for final redirection to the web service if the purchase is declined (see this article). For more information about managing options for redirecting the customer back to the web service, see this article. Example: |
|
Indicator specifying whether the payment form should be opened on a new HTML page for mobile devices (see this article).: Can have one of the following values:
If the Example: |
|
Indicator that specifies the mode for the final redirection of the customer to the web service when the purchase is completed (see this article):. Can have one of the following values:
For more information about managing options for redirecting the customer back to the web service, see this article. Example: |
|
URL for final redirection to the web service by customer decision when a purchase is completed (see this article). For more information about managing options for redirecting the customer back to the web service, see this article. Example: |
|
URL for preliminary redirection to the web service from third-party services such as banks and other payment systems (see this article). Requires this functionality (for specific third-party services) to be set up and enabled beforehand. For more information about managing options for redirecting the customer back to the web service, see this article. Example: |
|
Indicator that specifies the mode for the automatic final redirection of the customer to the web service when a token has been generated in Card Tokenize mode using the relevant payment details (see this article):. Can have one of the following values:
For more information about managing options for redirecting the customer back to the web service, see this article. Example: |
|
URL for automatic final redirection to the web service when a token has been generated in Card Tokenize mode using the relevant payment details (see this article). For more information about managing options for redirecting the customer back to the web service, see this article. Example: |
|
The country code for the customer's address (in the ISO 3166-1 alpha-2 format). Specified in the ISO 3166-1 alpha-2 format. If this parameter is not specified, the country code is determined using the customer's IP address or other parameters. Example: |
|
The name of the street and the house number (including any additional parts of the address such as building indicators and apartment numbers) in the address of the payment sender, at most 99 characters long. The length of the string cannot be more than 99 characters. Example: |
|
The name of the place of residence (e.g., town, city, or other settlement type) in the address of the payment sender, at most 25 characters long. The length of the string cannot be more than 25 characters. Example: |
|
The code of the country in the address of the payment sender (in the ISO 3166-1 alpha-2 format). Specified in the ISO 3166-1 alpha-2 format. Example: |
|
The first name of the payment sender, at most 255 characters long. The length of the string cannot be more than 255 characters. Example: |
|
The last name of the payment sender, at most 255 characters long. The length of the string cannot be more than 255 characters. Example: |
|
The local code of the region (state, province, or other administrative subdivision type) of the payment sender's address. The value of this parameter is the second element of a code for a subdivision (in ISO 3166-2), without the two-letter country code and the hyphen-minus used as a separator. Should be specified when the The local code of the region of the payment sender's address. Example: |
|
The identifier of the digital wallet used by the payment sender, at most 64 characters long. The length of the string cannot be more than 64 characters. Specified as is, without masked characters, spaces, or other separators. Example: |
|
The postal code in the address of the payment sender. The length of the string cannot be more than 255 characters. Example: |
|
The digital signature used to sign the query parameters (see this article). Should be generated using the appropriate algorithm after all relevant parameters have been specified (see this article). |
|
The identifier of the payment form design style. Can be used for the 5th generation Payment Page design style (see this article). The identifier of a 5th generation payment form design style (see this article). Example: |
|
The iframe element identifier (for the HTML page of the web service) of the element where the payment form should be opened for opening the payment form (see this article). Example: |
|
The identifier of the payment form terminal. Can be used for the 4th generation Payment Page design style or earlier (see this article). The identifier of a 4th generation payment form design style or earlier (see this article). Example: |
|
Identifier used for internal purposes. The length of the string cannot be more than 64 characters. Can be used to invoke the payment form in Payout mode by specifying the value received in the payout registration callback (see this article). Example: |