For the complete documentation index, see llms.txt. This page is also available as Markdown.

Direct Post

Direct Post allows a merchant to create payments or tokenize a credit card without having the customer's credit card details transmitted through their infrastructure, greatly reducing the scope for PCI-DSS.

When using Direct Post the communication of credit card details is between the customers browser and the Gateway, with the result being returned to the merchant via a GET request.

Benefits

Direct Post offers the following benefits over server integration or a hosted payment page:

  • Reduced PCI-DSS Scope (the full card number is not transmitted through your systems)

  • Control over branding and user experience

  • Easy and straight-forward to implement

  • Recurring payments are still possible with the returned card token

📘 It is important to note that while credit card data is not being transmitted through the merchants systems using Direct Post there is still a risk of data loss if the appropriate measures are not taken to protect the security of the integration (for example ensuring the integration has not been tampered with to divert traffic). All merchants using Direct Post must complete the PCI DSS Self Assessment Questionnaire SAQ A-EP and complete regular security checks including external scans performed by an Authorised Scanning Vendor.

Direct Post is supported for Purchases and Credit Cards.

Data Integrity

As the request to the Gateway and the response back to the merchant website is transmitted by the Customers browser data integrity measures have been put in place to ensure the critical data (amount, reference etc) are not modified. This verification is done using a signed hash with a shared secret. Before a request is accepted by the Gateway the data is verified against the hash provided and if this does not match the transaction is rejected. Specific details for the hash calculation are provided in each Direct Post operation's documentation, however an overview is provided below.

The verification value (the hash) is calculated using the following:

  • a string of key values joined with a colon (e.g. ABC123:1000:AUD)

  • the shared secret, known to both the Merchant and the Gateway - it is important that the shared secret be protected - should the hash need to be calculated dynamically this should be done server-side

The following example pseudo code demonstrates this process:

In some cases the result of the HMAC may result in binary data - it is important that the Hex Digest be used for the verification value.

JSONP support

In order to support submitting payments using AJAX the request needs to be sent using JSONP, as it is not possible to perform a Cross-domain request to the Gateway. To use JSONP:

Example script for performing a JSONP Direct Post request is below. Note: this script depends on jQuery.

Last updated