...
Transactions are broken up into delimited fields. A transaction is transmitted either in the request header for the GET method , or following the request headers for the POST method.
Changelog
| x_version | Description | Date |
|---|---|---|
| 1.13 | x_customer_id now allows for alpha-numeric characters, as well as, the special characters period ., underscore _, and dash - | 2021-06-15 |
Notes about the Merchant IDs and PINs
...
The Purpose of the x_payment_token_id field is to allow a “one-time” sending of the Credit Card number or the Route and Account number (for an ACH transaction) and then be able to reference it in the future without needing to send the card number or account number again. This allows an application to be developed where it does not have to store these sensitive numbers but instead, gotoBilling is the only place these numbers are stored securely. A future transaction may be as simple as needing to process a credit card refund or an ACH credit. This can now be accomplished if the associated x_payment_token_id from the original transaction is sent. Therefore, the application must keep a database of x_payment_token_ids for all transactions sent if future transactions using this field are to be performed. The following are the basic points regarding using this feature:
- Initially, the payment account information (CC Number, ACH Account) can be sent along with the x_payment_token_id.
- The account can then be accessed in the future by simply by passing the x_payment_token_id for the desired account. The individual account information is not needed.
- If any account information is passed with an existing x_payment_token_id. That account information will be updated to match the information given.
- The x_payment_token_id should be unique. Technically it only has to be unique per Customer ID (x_customer_id) but it might be easier to design if it is unique across the entire Merchant ID (merchant_id) so there’s no duplication at all. One suggestion would be to have the x_payment_token_id be the x_customer_id+(some value) where the value could be the date in YYYYMMDD format. This would facilitate easier research if needed and would likely be easier to implement than other numbering schemes. Especially since the x_customer_id must be unique across the Merchant ID.
IMPORTANT NOTE: Validation for the uniqueness of this field will be added in the future, however, it is not currently live.
...