19.0 Gateway Wallet

19.1 Background

The Gateway supports an internal digital Wallet that is available to all Merchants using the Gateway.

The Gateway allows you to store your Customer’s payment card, billing and delivery address details and other information securely encrypted in its internal Wallet. You can then allow your Customer to select from stored payment cards to check out faster on your website.

Management of this Wallet is done using the Gateway’s REST API. However, you can use the Hosted, Direct or Batch Integrations to perform transactions, using cards and addresses stored in the Wallet; or to store new cards and address used with successful transactions.

19.2 Benefits and Limitations

19.2.1 Benefits

• Details can be used from or added to the Wallet with just a few extra integration fields. 
• Customers can select from previously stored details, making the checkout process more streamlined, resulting in fewer abandoned carts and thus increasing sales. 
• Compatible with existing card base fraud solutions such as Address Verification Service (AVS), 3-D Secure and third-party fraud providers. 
• There are no extra costs to use the internal Gateway Wallet. 
• The Wallet transactions are controlled within the Merchant Management System (MMS) in the same manner as normal card transactions. 
• Stored cards are assigned a Card Token which is fully LUHN checkable PAN ending in the same last 4 digits as stored card and thus can be used to replace the PAN in any system that is expecting to store PANs and not arbitrary card identifiers. 

19.2.2 Limitations

• The payment details are stored internally by the Gateway and not available for use with other Gateway Merchants or other payment gateways

19.3 Hosted

If a transaction is sent to the Hosted Integration, then with the addition of a few extra integration fields, the Customer can be asked whether they wish to save their details in the internal Wallet for future use.

Customers who have payment details already saved will have the option to select from those details rather than having to renter them. Customers will also have the option to delete stored details ¹.

The details are only saved if the transaction is successful, ensuring that the Wallet is not filled up with invalid payment details. 

The details needing to be stored in the Wallet are validated when the transaction is performed, prior to any authorisation with the Acquirer. If any of the details are invalid, then the transaction will be aborted with a responseCode of 66304 (INVALID_REQUEST) and a responseMessage indicating which data could not be stored in the Wallet. Any failure that occurs post authorisation will not abort the transaction but will be available in the appropriate xxxxStoreResponseCode response fields. 

The walletOwnerRef field can be used to assign a unique Customer reference to the Wallet, allowing you to identify which of your Customers owns the Wallet. This could be the Customer reference you use within your own Customer accounts or Shopping Cart software. You must ensure that this value is less than 50 characters, or the transaction will be aborted with a responseCode of 65xxx (INVALID_WALLETCUSTOMERREF). 

1 There is no option to modify stored payment details. However, the Customer can delete them and then restore them.  

19.4 Direct Implementation

If a transaction is sent to the Direct Integration, then with the addition of a few extra integration fields, it can be instructed to use payment details stored in the Wallet and/or store the used payment details.

Using stored payment details is similar to performing cross-referenced transactions where the payment details are cloned from a previous transaction ¹. However, in this case the payment details are taken from the Wallet and not a previous transaction.

The details are only saved if the transaction is successful, ensuring that the Wallet is not filled up with invalid payment details.

The details requiring to be stored in the Wallet are validated when the transaction is performed prior to any authorisation with the Acquirer. If any of the details are invalid, then the transaction will be aborted with a responseCode of 66304 (INVALID_REQUEST) and a responseMessage indicating which data could not be stored in the Wallet. Any failure that occurs post authorisation will not abort the transaction but will be available in the appropriate xxxxStoreResponseCode response fields.

The walletOwnerRef field can be used to assign a unique Customer reference to the Wallet allowing you to identify which of your Customers owns the Wallet. This could be the Customer reference you use within your own Customer accounts or Shopping Cart software. You must ensure that this value is less than 50 characters, or the transaction will be aborted with a responseCode of 65xxx (INVALID_WALLETCUSTOMERREF).

1 Refer to appendices A-15 through to A-17 for details on cross referenced transactions and cloning.

19.5 Request Fields

19.6 Response Fields

If new items are stored in the Wallet, then their identifiers will be returned in the appropriate walletID, cardID, customerAddressID and deliveryAddressID together with any values provided for or assigned by default to the other item fields.

Failure to store any of the details in the Wallet will be reported using the appropriate xxxxStoreResponseCode response field.