Product Functionality & Step by Step Guides
Introduction
The axept® Gateway is a Web Service we provide for the processing of electronic payments. There are no requirements for any software to be installed to utilise the solution and it can be used to process payments across a variety of platforms including ecommerce (transactions processed via a website or mobile app) and MOTO (transactions processed via Mail Order or Telephone).
Utilising the axept® Gateway allows you to provide an 'invisible' payment processing experience to the cardholder; You will be completely responsible for the design of the webpages used to capture the card information and the flow of the payment. This is the main differential between axept® Checkout (the hosted payment page solution from Optomany) where the cardholder is redirected to a page created and hosted by us.
To assist your development approach, we have provided detailed integration guidance in this document and made WSDLs (Web Services Description Language) available.
Processing Features Supported by axept® Gateway
axept®Gateway has been designed using the latest technologies and supports the latest processing services. A full list of supported processing methods are detailed as follows.
Sale & Refund
axept® Gateway fully supports sales and refunds.
Account Verification
Several merchants accept orders from customers where it is not possible for the stock levels to be checked during the checkout process. On these occasions, the merchant wishes to check the validity of the card being presented but is not able to debit the full amount of the order until relevant checks have been made (such as stock availability etc.).
In scenarios such as this, merchants have traditionally performed what is known as a 'nominal' pre-authorisation for a small amount such as £0.01, £0.10 or £1.00. If the authorisation is successful, this is used by the merchant to show the card information is valid but the auth code obtained is never 'claimed' and eventually expires, returning the funds to the cardholder's available balance.
Recently the card issuers (VISA, Mastercard etc.) have issued various communications where this practise has been strongly discouraged and instances of declines have been reported by some merchants. To provide an alternative method of checking the card validity a new transaction type has been introduced - 'Account Verification'.
The submission of this request (with a zero-transaction value) will result in one of two results:
ACCOUNT VALID - Card details supplied are valid CANNOT VALIDATE - Card details supplied could not be validated
As part of the response issued by axept® Gateway, a merchant token is provided which can be stored in the merchant's system and used for the subsequent authorisation once the goods are ready for dispatch.
Whilst the axept® Gateway fully supports the Account Verification transaction type, Acquirer support is currently limited. Optomany are pushing hard to ensure that axept® Gateway support is added as soon as it is available with the other Acquirers. Please contact the Implementations team to discuss.
Cashback
Whilst the axept® Gateway has the facility to process transactions with cashback this is unlikely ever to be used. Merchants who require this functionality will most likely use one of Optomany's cardholder present axept® solutions.
Charitable Donation
Optomany have partnered with the charitable foundation Pennies to provide merchants the ability to offer cardholders the chance to donate money to charity whilst going through the payment process. Pennies presents merchants with the ability to offer two different types of donation:
Round-up When a cardholder agrees to 'round-up' the amount to be debited from the card is increased to the next available whole Pound/Euro. For example, a transaction for goods totalling £9.99 will lead to the cardholder being offered the chance to donate £0.01 to charity. If they choose to do so the card will be debited for £10.00.
Top-Up When the round up option is not suitable (a merchant whose goods are generally priced at a rounded value, for example: £5.00) it is possible to nominate a set value of less than a pound that the cardholder can be prompted to donate. If accepted by the cardholder the amount is added to the transaction value.
In all cases the charitable donation amount is passed separately in the request and is shown as such on the OCC reports.
Gratuity
Whilst unlikely to be used in the environments in which axept® Gateway operates, it is possible for gratuities to be added to a sale if required.
Surcharge
axept®Gateway allows integrators to add a surcharge to their transactions if required. This could be used in environments where processing specific card types (such as Discover/Diners for example) incurs higher banking charges that they desire to be passed on to the cardholder.
Payer Authentication (3DSv1)
Payer Authentication is used by the card schemes as an additional mechanism to validate that the cardholder is physically present during the authorisation of their card. The process requires a cardholder to register their card with the scheme (which can be done during the payment process) and setup a password which will be used (or digits from the password) each time a transaction is processed via the web with participating merchants.
As Payer Authentication has developed some card issuers (such as Monzo) are now using two factor authentication (2FA) in place of the traditional password verification. When 2FA is used the consumer is usually either texted a security code to enter or asked to acknowledge a notification sent to their mobile app.
Following the introduction of the Strong Customer Authentication Directive, currently scheduled for September 2021, it is expected that 3DSv1 secured payments will see acceptance rates drop. For more details on the Payer Authentication process, see section 6.7 Payer Authentication.
Payer Authentication (3DSv2.0)
3DSv2 represents a step forward in both security and ease of use. It is designed to be less intrusive than the first version of the specification, allowing more contextual data to be sent to the Issuer to verify and assess the risk of the transaction. Our Gateway allows Integrators to collect and pass through this wide variety of optional data. The cardholder would only be required to pass an authentication challenge if their transaction is determined to be of a high risk.
Several other ease of use improvements have been made to ensure the user experience for the cardholder is smoother, including a better redirection mechanism and the use of Two Factor Authentication via an issuing institution's mobile app, for example.
For more details on this new scheme, see section 5.10 PayerAuthentication 3DSv2.0
Tokenisation
To assist our partners and merchants with the requirements of PCI-DSS, the axept® Gateway supports the tokenisation of card details across multiple solutions. Tokenisation allows merchants to register a cardholders PAN and expiry date securely and most importantly on Optomany's systems thus keeping stored card data off their own networks. The Optomany token is consistent across all products and solutions meaning that the same card processed on the same merchant account regardless of channel will produce the same token ID.
Whenever card details are provided axept® Gateway will always return a 'Merchant Token' to the integrator. If it is not required, it can be ignored. The following is an example of the token format provided by axept® Gateway:
zT55LH3SQvwMVSIIv7yMIFRyhxIgS2sXiJRamfG2bSIfNDkyOTEy*
Encrypted Card Information
axept® Gateway does not accept non-encrypted card information when processing a transaction request. To send a transaction request, the card information first must be encrypted using the below process.
- Card details captured on a secure page within the merchant's website.
- When the cardholder selects 'Pay', a request HTTP Form Post is sent direct from the cardholder's browser to the axept® Gateway's card encryption service requesting that the card data be encrypted.
- The card encryption service then responds and provides merchant with encrypted card data.
- Encrypted card data is then used to complete the transaction authorisation process.
Any attempt to process a transaction without first performing the above will be met with an error from axept® Gateway. Further details on this process available in section 5.4 Card Encryption Request. Details regarding Local Encryption (using an RSA key supplied by Optomany to locally encrypt the card data prior to transmission) can be found in section5.2.2 Local Encryption using RSA.
Authorisation Reversals
Once an authorisation has been completed, the Acquirer issues an authorisation code which reserves the funds requested for the merchant. The amount of reserved funds are then removed from the cardholder's available balance.
This authorisation code is then 'claimed' once Optomany receive a settlement request for the transaction and the subsequent overnight settlement process is completed by Optomany. However, there may be occasions where the merchant may not want to continue with the transaction despite an authorisation code being issued. An example of this could be when a merchant wishes to abort a transaction based upon the results of the Address Verification or Cardholder Security Code checks.
If successful (not all reversals will be possible at the Acquirers end) the completion of the reversal process returns the money reserved under the authorisation code back to the cardholder's available balance. Further details on reversals is provided by the UK Cards Association:
Explicit reversals are identified by use of a reversal message type and rely on specific data in the reversal request message enabling the acquirer to identify the original transaction request. Generally, this is limited to the reversal transaction being the next message from the same TID, with the same card details and amount, as the transaction being reversed. The message number is incremented by one from the message being reversed and there may also be a time limitation between the time of the reversal request and the time of the original transaction.
On receipt of the response message the terminal shall void the transaction and print a receipt message appropriate to the stage the transaction has reached when it is reversed.
In an 'Authorisation Only' environment, a reversal may not immediately follow the original authorisation request, and may be for a different amount (a partial reversal), if the original authorisation was for an amount greater than the final purchase amount (for example in a hotel environment). The reversal may also be sent from a different TID to that used for the original authorisation request (for example where TID availability is generated on a 'round-robin' basis), or from a different card acceptor to that used in the original authorisation request (for example in a car hire environment, where the vehicle is returned early to a different branch of the car hire company).
In these cases, the reversal request shall contain additional data (received in the auxiliary record part of the response to the original authorisation request) that will be used by the acquiring host to retrieve the original transaction, for example the Acquirer reference data data element. The inclusion of this unique Acquirer reference data data element provides an extended time frame (maximum 48 hours depending on file submission) for reversal processing between the card acceptor and acquirer.
Using this additional data to match the reversal request with the original sale allows the acquirer to send a reversal to the issuer to update the cardholder's open to buy. The card acceptor shall ensure that no settlement file, containing the original transaction, has been submitted to the acquirer and that the unique Acquirer reference data data element is stored and protected in compliance with card scheme and acquirer rules e.g. PCI-DSS. The Acquirer reference data data element also allows the acquirer to validate that a reversal is genuine. When returned in a response message, the terminal shall store the data securely, e.g. the value shall not be printed on the cardholder or card acceptor receipt. The data cannot therefore be readily obtained for inclusion in a counterfeit reversal message. When received in a reversal message, the acquirer may verify that the data element received in the reversal message matches the same data element previously sent in the associated response message. The UK Cards Association - Standard 70 - Book 1
For more information regarding Authorisation Reversals, see section 5.12 Authorisation Reversals
Stored Credential Transaction Identification
Growth in digital commerce and the emergence of new business models has increased the number of transactions in which the payment solution stores the cardholder's payment credentials, which are the cardholder's account details, for future use. A transaction using stored credentials may occur when a cardholder has provided the card acceptor with their payment credentials for use with future purchases. Recognising stored credential transactions distinctly allows for greater visibility into the transaction risk, enabling robust processing and higher approval rates.
Identifying stored credential transactions specifically allows for differentiated treatment through the authorisation approval process. The benefits are:
- Greater visibility of transaction risk levels for issuers
- Higher authorisation approval rates and completed sales
- Fewer customer complaints and improved cardholder experience
axept® Gateway accepts a wide range of applicable Transaction Types, as detailed in section 5.10.6 CredentialOnFile.
Transaction Submission
Once a transaction has been successfully authorised the integrator must decide whether they wish to settle the transaction. The settlement process involves the sending of a Settlement Request to axept® Gateway and if successful the transaction details being sent to the merchant's Acquirer overnight. The overnight process then sees the funds 'claimed' from the cardholders account and placed into the merchant's account.
In 99.9% of transactions, the submission request will be sent instantly after the transaction result has been received but having the option not to do so could be useful in certain scenarios. For example, when there is a query regarding stock of an item. The submission request could be sent once confirmation that the item is available has been received.
The submission request can be sent in the background and therefore does not slow down the transaction process for the consumer. The Optomany Control Centre (OCC) can report on the settlement status of transactions should any manual checking need to be completed.
Another instance where a delayed settlement may be required is when the shipment of goods are delayed. The authorisation is completed at the point of order, but the settlement request is not made until the shipment is confirmed. The main consideration in this process is ensuring that the authorisation code gained during the initial authorisation has not expired. There is no 'hard and fast' expiration date for auth codes, but they can last between 3 to 10 days depending on the card issuer involved.