Exact Payments Hosted Checkout Integration Guide
Once integrated with a merchant’s website, the cardholder’s payment information is handled by the Exact Payments payment page. Following payment, transaction results are returned to the merchant and their customer. This allows clients to easily track and process orders online. Exact’s Payment Pages provide:
- Reduced PCI scope
- Rapid integration
- Optimization for mobile devices
- Modern payment options: Apple Pay, Google Pay, PayPal
- Support for both Level II and III data
Payment Page settings are configured through the “Payment Pages” tab on the Exact Payments Gateway Administration Page. See our Payment Pages Setup guide, here: https://developer.exactpay.com/docs/hosted-checkout-set-up
The following information is intended for web-developers and merchants looking for a better understanding of the Exact Payments Payment Pages flow.
Introduction
Payment Pages redirect the customer from the merchant website to a payment form hosted by Exact Payments. To accomplish this the merchant displays a "Checkout" button, or similar, within an HTML form on their website. This form then submits a POST request to the following URL: https://checkout.exactpay.com/payment; Sandbox test transactions are submitted to: https://checkout.exactpaysandbox.com/payment. Within the parameters of the HTML form the merchant specifies the payment details and authentication information. These are usually implemented as hidden inputs. The appearance of the payment page is configured through an online management interface available to all Merchant Administrator users.
URL Endpoints
Production URL: https://checkout.exactpay.com/payment
Sandbox URL: https://checkout.exactpaysandbox.com/payment
Essential Fields
The following parameters are required, and validated, with each transaction request. If one is missing, or the validation fails, an error page is displayed to the cardholder. The merchant will also receive an email explaining the problem. All characters must be UTF-8 encoded.
Field |
Value |
Description |
x_login |
Varies by merchant and payment page |
Maximum length 20, the Payment Page ID from the Exact Payment Pages interface. Case-sensitive. |
x_fp_sequence |
Chosen by merchant |
Can be a random number. Used in x_fp_hash calculation in order to make it unique but not used otherwise. Returned with Relay Response / Silent Post / Receipt Link. No length restriction. |
x_fp_timestamp |
Time in seconds since January 1, 1970. UTC, Coordinated Universal Time |
Requests expire after 15 minutes / 900 seconds. |
x_amount |
Equal to or greater than 0 |
Total dollar amount to be charged inclusive of freight and tax; Maximum Length 15. Zero dollar Authorizations can be performed: Typically this is done in scenarios where the card details need to be verified and tokenized, but not charged immediately. Performing this type of transaction can be done by submitting "0" as the dollar amount and submitting "x_type" as "AUTH_ONLY". Note that in the aforementioned case the hosted checkout page presented to the cardholder will not include the dollar amount. Instead of a "Pay With Your Credit Card" button, the consumer will see a "Submit" button. |
x_fp_hash |
String |
HMAC-SHA256 hash from the merchant’s transaction key and concatenation of the values for x_login, x_fp_sequence, x_fp_timestamp, x_amount, and (if given)x_currency_code – all separated by the ^ character. Note that even if x_currency_code is not present a ^ character is still added. The transaction key can be found in the "Security" tab when viewing the settings for a specific Payment Page. This field must be lower case. |
x_show_form |
PAYMENT_FORM |
Case-sensitive. |
Hash Calculation and Security
The x_fp_hash value input field must be calculated separately for each checkout form. One of the inputs that this value depends on is a timestamp: a payment request with a timestamp that is 15 minutes or older will be rejected by the Payment Page. The x_fp_hash parameter serves solely as verification that the form was generated by the merchant's server, and not by the customer or a third party. Its calculation depends on the merchant’s private Transaction Key.
The x_fp_hash calculation is performed using the HMAC-SHA256 key (the Transaction Key from the Payment Page configuration) and the HMAC-SHA256 message, or payload. It is the concatenation of x_login, x_fp_sequence, x_fp_timestamp, x_amount, and x_currency_code (if used) – all separated by the caret (^) character (see "Essential Fields", above). The value of the Transaction Key can be found within the “Security” tab of the Payment Page configuration menu.
Transactional and Display Fields
These parameters are validated as indicated below. If invalid, one of the following two scenarios will occur:
- The customer's browser will display an error page and the merchant will be notified by email
- A default value will be substituted
The parameters are passed on as received by the Exact Payment Pages in:
- Error notification to the merchant
- Relay Response / Silent Post / Receipt Link
Name/Area |
Validation |
Description |
x_type |
AUTH_CAPTURE / AUTH_ONLY |
The type of the transaction. AUTH_CAPTURE is Purchase/Sale. AUTH_ONLY known as Authorization / Preauthorization ORDER will invoke a PayPal order transaction; other payment methods will not be displayed to the cardholder. |
x_gateway_id |
Gateway ID |
If the Payment Page is set up to use all terminals, this value must be populated with the Gateway ID of the desired terminal. |
Receipt Page Fields |
|
|
x_receipt_link_method |
LINK / GET / POST / AUTO-GET / AUTO-POST |
Specifies the type of link made back to the merchant's website. Case-sensitive. |
x_receipt_link_text |
Any text |
Hyperlinked text or submit button value. With GET or POST a form is generated with hidden fields that contain the result of the processed transaction. If empty, default value "Return to Merchant website title" is used. Merchant website title is set in the Payment Pages interface. |
x_receipt_link_url |
Valid URL |
Target of hyperlinked text or action for HTML GET/POST. If empty, or invalid URL, the default value from the Payment Pages interface is taken. |
Fields Common to Payment Collection and Receipt Page |
|
|
x_logo_url |
Valid URL |
Displayed on header of Payment Form and Receipt Page. If empty or not a valid URL, the default value from the Payment Pages interface is taken. |
x_color_background |
HTML color name or hex code |
Background color of the Payment Form and Receipt Page. If empty or invalid, default value from the Payment Pages interface is used. |
Email Setting Fields |
|
|
x_email_customer |
TRUE / FALSE |
Should a confirmation email be sent to the customer; default is set in the Payment Pages interface. |
x_merchant_email |
Valid email address |
Email address to which the merchant's copy of the customer confirmation email should be sent. If a value is submitted an email will be sent to this address as well as the addresses configured in the "General" section of the Payment Pages interface. No email will be sent to this address if it does not meet standard email format checks. |
Transaction Data Fields |
|
|
x_currency_code |
Currency of the transaction. Case sensitive. |
|
Recurring Billing Fields |
|
|
x_recurring_billing |
TRUE / FALSE |
To enable Recurring functionality through Payment Pages, this must be set to TRUE |
x_recurring_billing_id |
Plan identifier |
HCO Plan ID (retrievable by viewing a Recurring plan in the administrative interface) |
x_recurring_billing_amount |
Positive number |
The amount that will be billed each time a Recurring payment is run |
x_recurring_billing_start_date |
YYYY-MM-DD |
Optional; sets a custom start date for Recurring payments (otherwise it will be inherited from the Plan default) |
x_recurring_billing_end_date |
YYYY-MM-DD |
Optional; sets a custom end date for Recurring payments (otherwise it will be inherited from the Plan default) |
Ecommerce_flag |
Positive number |
The value passed in this flag can be used to classify the type of payment being performed. Possible values are outlined here. |
Order and Customer Detail Fields
The parameters below describe the order and customer fields; all are optional. They are passed as received by Exact Payment Pages via:
- Notification emails to the merchant about errors
- Relay Response / Silent Post / Receipt Link
Important Note: To enable Level 3 field support, you must enable the "Level 3 Processing" option on the General tab of the Payment Page or pass this parameter in your request:. You must also enable it on the General Setting tabs during the Payment Pages configuration.
<input name="enable_level3_processing" type="hidden" value="TRUE" />
NOTE: Enabling the Level 3 check box does not automatically allow you to submit Level 3 data. Level 3 acceptance must also be enabled on the merchant account.
Order Information Fields |
Description |
x_cust_id |
Not validated. Unique identifier for the customer associated with the transaction. Not displayed to the customer |
x_invoice_num |
Merchant-assigned invoice number. Truncated to the first 20 characters and becomes part of the transaction. It appears in column “Ref Num” under Transaction Search and “TRANS. REF” in the CTR (customer transaction record). The following characters will be stripped from this field: ; ` " / % as well as -- (2 consecutive dashes). |
x_customer_tax_id |
Not validated. Tax ID of the customer. Not displayed to the customer. |
x_line_item |
This parameter may occur several times (with different items). The item details are displayed on the Payment Page and receipt page for the customer's reference. Fields with this name contain itemized order information delimited by the three characters <|> The format is: Item ID<|>Item Title<|>Item Description<|>Quantity<|>Unit Price<|>Taxable (Y or N)<|>Product Code<|>Commodity Code<|>Unit of Measure<|>Tax Rate<|>Tax Type<|>Tax Amount<|>Discount Indicator<|>Discount Amount<|>Line Item Total For Level 3 to qualify, the above fields are Required: Item Description, Quantity, Product Code,Commodity Code, Unit Price, Unit of Measure, Tax Amount, Discount Amount, and Line Item Total. The size limit for Item ID, Item Name, Item Description, Item Quantity is 255 characters each. There is a limit of 99 line items for a single transaction. Additionally, the product of Item Quantity multiplied by Item Price must be in the range between -1,000,000,000 and 1,000,000,000 |
x_po_num |
Purchase order number. Truncated to the first 20 characters and becomes part of the transaction. It appears in column “Customer Reference Number” under Transaction Search. It does not appear in the receipt. The following characters will be stripped from this field: ; ` " / % as well as -- (2 consecutive dashes). For two stage transactions (pre-auth/completion), the reference number (x_po_num) at the time of pre-authorization will be used at time of transaction completion. An override of this value is not supported. The consistent usage of values enables a merchant to achieve the best interchange rates and least re-authorizations. Typically, the reference number field is the purchase order number or unique sequence value associated with a given transaction suite. |
x_description |
Not validated. Description of the transaction. Not displayed to the customer. |
x_reference_3 |
Additional reference data. Maximum length 30 and becomes part of the transaction. It appears in column "Reference Number 3" under Transaction Search. It does not appear in the receipt. The following characters will be stripped from this field: ; ` " / % as well as -- (2 consecutive dashes). Required Character Format is ASCII. |
Customer Name and Billing Address Fields |
|
x_first_name |
For billing address Required Character Format is ASCII. Max. Field Length: [30] - (First & Last Name Combined) |
x_last_name |
For billing address Required Character Format is ASCII. Max. Field Length: [30] - (First & Last Name Combined) |
x_company |
For billing address Required Character Format is ASCII. Max. Field Length: [30] |
x_address |
For billing address Max. Field Length: [28] (longer length will lead to a rejection of the transaction) |
x_city |
For billing address Required Character Format is ASCII. Max. Field Length: [20] |
x_state |
For billing address; Must be submitted as full name ie: Georgia, Maryland, Quebec Max. Field Length: [2] |
x_zip |
For billing address Max. Field Length: [10] |
x_country |
For billing address; Must be submitted as full name ie: United States, Canada Max. Field Length: [2] |
x_phone |
For billing address Max. Field Length: [14] |
x_fax |
For billing address Max. Field Length: [14] |
Customer Shipping Address Fields |
|
x_ship_to_first_name |
For shipping address Required Character Format is ASCII. |
x_ship_to_last_name |
For shipping address Required Character Format is ASCII. |
x_ship_to_company |
For shipping address Required Character Format is ASCII. |
x_ship_to_address |
For shipping address |
x_ship_to_city |
For shipping address Required Character Format is ASCII. |
x_ship_to_state |
For shipping address; Must be submitted as two letter code. e.g. CA, TX. |
x_ship_to_zip |
For shipping address |
x_ship_to_country |
For shipping address; Must be submitted as two letter code. e.g. US |
Additional Customer Data Field |
|
x_customer_ip |
IP address of the customer. Max. Field Length: [15] |
x_email |
Email address to which the customer's copy of the confirmation email is sent. No email will be sent if the email address does not meet standard email format checks. Max. Field Length: [30] |
Level 3 Fields |
|
x_tax |
Non-negative Number. The tax in dollars. (Required for Level III qualification) Max. Field Length: [12] |
x_tax_exempt |
TRUE / FALSE |
x_freight |
Non-negative Number. Freight charge in dollars. (Required for Level III qualification)
Max. Field Length: [12] |
x_duty |
Non-negative Number. Duty in dollars. (Required for Level III qualification) Max. Field Length: [12] |
alternate_tax |
Non-negative Number. The alternate tax in dollars. Max. Field Length: [9] |
discount_amount |
Non-negative Number. The total discount amount applied to a transaction. (Required for Level III qualification) Max. Field Length: [12] |
tax_rate |
Non-negative Number. Submitted as a percentage value (ie. 12) Max. Field Length: [4] |
x_fee_amount |
Equal to or greater than 0 Total fee amount in dollars to be charged; Maximum Length 15. This is added to x_amount to produce total charged. Specifying x_fee_amount overrides any amount calculated by the fees configuration for terminal. Ignored if fees are not enabled for terminal. Max. Field Length: [15] |
Notes on Additional Amount Fields: the x_tax, x_freight, x_duty amounts are for display within the order information and order confirmation emails only. Payment Pages perform no calculations with these numbers. They are passed back to the merchant with Relay Response, Silent Post, and Receipt Links.
Soft Descriptor Fields
The following properties are used to set soft descriptor information for a transaction on a case-by-case basis. Note: Dynamic soft descriptors are submitted only at settlement time and are NOT utilized during authorization. Meaning that the dynamic nature of the descriptor will not show on a pending authorization statement, but will show on the statement once the transaction has settled
Field |
Comment |
x_sd_dba_name |
Business name Required Character Format is ASCII. |
x_sd_merchant_contact_info |
Business contact information Required Character Format is ASCII. |
x_sd_street |
Business street |
x_sd_city |
Business city Required Character Format is ASCII. |
x_sd_region |
Business region Required Character Format is ASCII. |
x_sd_country_code |
Business country |
x_sd_postal_code |
Business postal/zip code |
x_sd_mid |
Business MID number |
x_sd_mcc |
Business MCC number |
Google Analytics
Field |
Explanation |
x_ga_tracking_id |
Use this field to pass Tracking ID from Google Analytics |
Relay Response
This response method involves an HTTP request ↔ response between Exact Payments and a merchant’s server, at the end of which Exact Payments relays the response content to the customer. The steps are:
- Exact makes an HTTP POST request containing the transaction results to the merchant server ("Transaction Result Fields" for details on the data that is sent).
- The merchant server responds with HTML content
- Exact displays the response content to the customer
Step 1 allows the merchant to receive transaction results in real time, which can then be used to update databases, inventory, empty shopping carts, etc.
Step 2 lets the merchant return a customized receipt via the HTML response returned to the Exact Payments Gateway.
The merchant server response must be in HTML format, and is passed on to the customer's browser for final display. If the merchant server response in Step 2 is not received within 25 seconds, in Step 3 Exact displays the standard transaction receipt to the customer. It is important to note that Exact is expecting a response from the merchant.
No sensitive transaction related data is transmitted to the merchant server.
Typically Relay Response is only performed for successful transactions. However, if the customer's payment attempts fail three times a “Transaction Declined” message is posted to the merchant's server for Relay Response.
In order to trigger Relay Response, set the following parameters in the payment request:
Field |
Value |
Description/Comment |
x_relay_response |
TRUE |
Required for Relay Response. Case sensitive (FALSE is not allowed) |
x_relay_url |
Payment Pages Configuration |
Optional. The URL to which the gateway posts the response. Validated with the value configured in the Payment Pages interface. If empty, the URL from the Payment Pages interface is used. |
Silent Post
This option is enabled by adding a “Silent Post URL” to the “Receipt Page” tab of the Payment Pages interface.
Silent Post performs the same Step 1 as Relay Response, sending the same transaction result fields. But in Step 2, the HTML content (if any) in the merchant server's response is ignored by the Exact Payments Gateway, and the process ends there.
Note: there is no guarantee of sequence - for example if both Silent Post and Relay Response are enabled, the merchant server cannot assume the data will always arrive first from Silent Post or vice versa.
Troubleshooting:
1) A merchant must accept and respond to the Silent Post with an HTTP 200 (This is the only accepted HTTP response)
2) Ensure no redirect information/headers are being sent (this is a server to server request)
Transaction Result Fields
Basic Relay Response and Silent Post Fields
Field |
Description |
Explanation |
x_response_code |
Response code |
1 for “Approved”, 2 for “Declined”, 3 for “Error” |
x_response_subcode |
Response Subcode |
Internal value. Future use. |
x_response_reason_code |
Response Reason Code |
See table under Section 9.6 Response Reason Codes and Text, below. |
x_response_reason_text |
Response Reason Text |
See table under Section 9.6 Response Reason Codes and Text, below. |
x_auth_code |
Approval Code |
Authorization number of the transaction |
x_trans_id |
Transaction ID |
Unique identifier |
x_SHA1_Hash |
SHA1 Hash |
SHA1 Hash, in hexadecimal, of the concatenation of these strings:
|
exact_ctr |
Receipt |
Exact Payments generated Customer Transaction Record (CTR) |
x_payment_id |
Payment ID |
Used to make subsequent transactions through the API |
Transaction Examples
Basic example:
<form action="https://checkout.exactpay.com/payment" method="post">
<input name="x_login" value="WSP-EP-00101" type="hidden">
<input name="x_amount" value="10.00" type="hidden">
<input name="x_fp_sequence" value="123456" type="hidden">
<input name="x_fp_timestamp" value="1634559078" type="hidden">
<input name="x_fp_hash" value="NEEDSVALUE" type="hidden">
<input name="x_show_form" value="PAYMENT_FORM" type="hidden">
<input value="Checkout" type="submit">
</form>