Hosted Payment Page Integration Guide

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 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:

  1. 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).
  2. The merchant server responds with HTML content
  3. 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:

  • Relay Response Key
  • x_login
  • Transaction ID (field x_trans_id)
  • Amount, two digits after the period ($100 is used as “100.00”)

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-­001­01" 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>