If you need sensitive cardholder data for future use (e.g. to allow one-click shopping for registered customers or to trigger subsequent transactions), you can use a token to reference to the data at a later point so that you do not need to store these details within your own systems.
If you use a HTML form to initiate the payment, you can send the parameter
hosteddataid together with the transaction data as a unique identification for the payment information in this transaction.
Depending on the payment type, credit card number and expiry date or IBAN and account holder name will be stored under this ID if the transaction has been successful. In cases where the submitted
hosteddataid already exists for your store, the stored payment information will be updated.
If you want to assign multiple IDs to the same payment information record, you can submit the parameter
hosteddataid several times with different values in the same transaction.
If you prefer not to assign a token yourself but want to let the Gateway do this for you, send the parameter
assignToken and set it to ‘true’. The Gateway will then assign a token and include it in the transaction response as
If you have use cases where you need some of the tokens for single transactions only (e.g. for consumers that check out as a “guest”, use the additional parameter
tokenType with the values ‘ONETIME’ (card details will only be stored for a short period of time) or ‘MULTIPAY’ (card details will be stored for use in future transactions).
If you stored cardholder information using the token, you can perform transactions using the
hosteddataid without the need to pass the credit card or bank account data again.
Please note, that it is not allowed to store the card code (in most cases on the back of the card) so that for credit card transactions, the cardholder still needs to enter this value. If you use Fiserv's hosted payment forms, the cardholder will see the last four digits of the stored credit card number, the expiry date and a field to enter the card code.
When using multiple Store IDs, it is possible to access stored card data records of a different Store ID then the one that has been used when storing the record. In that way you can for example use a shared data pool for different distributive channels. To use this feature, submit the Store ID that has been used when storing the record as the additional parameter
To avoid customers using the same cardholder data for multiple user accounts, the additional parameter
declineHostedDataDuplicates can be sent along with the request. The valid values for this parameter are ‘true’/’false’. If the value for this parameter is set to ‘true’ and the cardholder data in the request is already found to be associated with another
hosteddataid, the transaction will be declined.
Updated 9 months ago