In addition to authorizations, our API offers a range of other payment types including Credits and OTBs (Open To Buy). Whether you're using one of our SDKs or are integrating directly to our API, this guide gives an overview of each transaction type and example request/response values for each one.
Authorization
Once you have the card data captured in your application you can send it on to Global Payments to be checked, sanitized and formatted in the correct way to be sent to be processed. Merchants capturing data in their application (and on their server) should be aware of their PCI DSS compliance responsibilities.
To understand how to utilize Credential on File functionality in relation to this request type, please refer to the following section of the API reference.
We highly recommend sanitizing the cardholder data before sending it in the request. For example, you can check the card number is valid and the expiry date is in the future. Our JS Library contains a handy set of functions to help you do this.
Sample request
<?xml version="1.0" encoding="UTF-8"?>
<request type="auth" timestamp="20180613141207">
<merchantid>MerchantId</merchantid>
<account>internet</account>
<channel>ECOM</channel>
<orderid>N6qsk4kYRZihmPrTXWYS6g</orderid>
<foreignretailer flag="false"/>
<amount currency="EUR">1001</amount>
<card>
<number>4263970000005262</number>
<expdate>0425</expdate>
<chname>James Mason</chname>
<type>VISA</type>
<cvn>
<number>123</number>
<presind>1</presind>
</cvn>
</card>
<autosettle flag="1"/>
<sha1hash>87707637a34ba651b6185718c863abc64b673f20</sha1hash>
</request>Validate (OTB)
Open to Buy (OTB) allows you to check that a card is still valid and active without actually processing a payment against it. The Security Code (CVN) and Address Verification Service (AVS) checks will also be performed against it. This is an alternative to charging the card a small amount (for example €1) to obtain the same result.
To understand how to utilize Credential on File functionality in relation to this request type, see the API Reference for Card Storage.
It is possible to set the Fraud Filter mode to ACTIVE for OTB transactions. This can be configured by setting the Fraud Filter Mode as ACTIVE. This field is available in the API Reference for Fraud Management.
Sample request
<?xml version="1.0" encoding="UTF-8"?>
<request type="otb" timestamp="20180613141207">
<merchantid>MerchantId</merchantid>
<account>internet</account>
<orderid>BA5qJD1DQMuNNocGU_y3HQ</orderid>
<foreignretailer flag="false"/>
<card>
<number>4263970000005262</number>
<expdate>0425</expdate>
<chname>James Mason</chname>
<type>VISA</type>
<cvn>
<number>123</number>
<presind>1</presind>
</cvn>
</card>
<sha1hash>11e5d2ce54eec98892155715497e5c4c4866d998</sha1hash>
</request>Credit
This request type allows you to credit an amount to a customer's card. To process this request you must supply the Refund Password, which you can set with a member of our support team (note: this is a different password than the Rebate Password). This password must be hashed using the SHA-1 algorithm before being added to the request. Credit requests are not sent on to the Issuer; they are placed directly into the next day's settlement file.
For security reasons, this request type is not enabled by default. It must be requested by one of the listed contacts on your Global Payments account.
Sample request
<?xml version="1.0" encoding="UTF-8"?>
<request type="credit" timestamp="20180615094902">
<merchantid>MerchantId</merchantid>
<account>internet</account>
<orderid>klmnjrTQRpaseGCzKCYCpQ</orderid>
<foreignretailer flag="false"/>
<amount currency="EUR">1999</amount>
<card>
<number>4263970000005262</number>
<expdate>0425</expdate>
<chname>James Mason</chname>
<type>VISA</type>
</card>
<refundhash>e51118f58785274e117efe1bf99d4d50ccb96949</refundhash>
<sha1hash>c9f606ca80b0c691628537dc662f4002b5d6e78e</sha1hash>
</request>Offline
Some authorizations will be declined with a code 102 response, the message will be REFFERAL B or similar. These transactions may still be authorized using the Offline request type. Merchants must manually obtain an authorization code for transactions of this type. Typically, this involves contacting the Acquirer authorization center by phone.
The Offline transaction will be linked to the original transaction for which the REFERRAL B result was received. The original Order ID and Payments Reference are required.
Sample request
<?xml version="1.0" encoding="UTF-8"?>
<request type="offline" timestamp="20180731090859">
<merchantid>MerchantId</merchantid>
<account>internet</account>
<orderid>BA5qJD1DQMuNNocGU_y3HQ</orderid>
<authcode>12345</authcode>
<pasref>1461142363479682</pasref>
<comments>
<comment id="1">Auth Centre</comment>
<comment id="2">ID#45478</comment>
</comments>
<sha1hash>ab3d8aebae75d96c44cdf28d03409e54ba04b39d</sha1hash>
</request>Supplementary data
The supplementary data elements can be used to include any amount of extra data in the request and can be used in Authorization, Credit, Refund (Rebate) and Capture (Settle) requests. The value of each field is available in reports downloaded from Ecommerce Portal. Some merchants may also use these elements to pass on additional transaction information to their Acquirer.
Request syntax
| Element/Field | Category | Format | Type | Length | Description |
|---|---|---|---|---|---|
| Item | string | alphanumeric | O | 0-20 |
The first element defines the data type to be supplied in the subsequent fields. For example, <item type="logData"> |
| Field# | string | alphanumeric | O | 0-100 | There can be up to 14 data fields for each item element; <field01> up to <field14>. |
Generate hash
Follow the steps in this section to build the request security hash, concatenate the specified fields and hash them using the SHA-1 algorithm, concatenate the hashed string with your Shared Secret, hash it again, and add the resulted string to the request.
In addition to SHA-1, you can also generate your hash using SHA-256. The resulting hash should be placed in the <sha256hash> tag instead of the <sha1hash> tag. For more information, contact our support team at ecomsupport@globalpay.com.
Build the Request hash
Use the dropdown below to select a request type: Authorization, Validate (OTB), Credit, or Offline. After making a selection, the steps on how to build the request hash for that type are provided.
Check hash
Follow the steps in this section to build the response security hash, concatenate the specified fields and hash them using the SHA-1 algorithm, concatenate the hashed string with your Shared Secret, hash it again, and add the resulted string to the request.
Check the Response hash
Use the dropdown below to select a request type: Authorization, Validate (OTB), Credit, or Offline. After making a selection, the steps on how to check the response hash for that type are provided.