Terminals APIs
Integration
The accounts below are accepted by the host emulator's validation mechanism and, thus, can be used for preliminary testing. They are also used as part of the certification process. In case if it is necessary to test the tokenization process, it is possible to use the test card/bank account numbers listed below and live card/bank account numbers. For more details review this note.
| Card Type | Card Brand | Card Number | Expiration Date | Token (Simple) | Token (Extended) |
| Credit | VISA | 4111111111111111 | 0430 | VC84632147254611111111 | XVC01P0000000084632147254611114111001111 |
| Credit | MasterCard | 5499740000000057 | 0430 | MC32541698745800570057 | XMC01P0000000032541698745800575499000057 |
| Credit | Discover | 6011000991001201 | 0430 | DC65874123589012011201 | XDC01P0000000065874123589012016011001201 |
| Credit | AmEx | 371449635392376 | 0430 | AC21548730012123762376 | XAC01P0000000021548730012123763714002376 |
| Debit | VISA | 4217651111111119 | 0430 | VD57543852138455552229 | XVD01P0000000029832298045816474217001119 |
| Debit | MasterCard | 5149612222222229 | 0430 | MD48963129999944441119 | XMD01P0000000062379363405796695149002229 |
| Country | Bank Account Number | Token (Simple) | Token (Extended) | Routing Number | Account Type |
| US | 4099999992 | BC11190000010030019992 | XBC00P0000000011190000010030014099009992 | 021000021 | Checking |
| AU | 7694200031 | BC12345667081067830031 | XBC00P0000000012345667081067837694000031 | 093088 | Checking |
| CA | 5682100032 | BC12345644275009280032 | XBC00P0000000012345644275009285682000032 | 053133052 | Checking |
As part of testing, the amount ranges specified below can be used to trigger specific response codes from the server. Any valid account number and properly formatted billing address can be used for the test.
When working with test amount ranges, pay attention to the asterisks in the table below:
*D08/D21 response codes apply only in the cases when CSC/PIN code has been submitted. Otherwise, A01 Approved is returned.
**This range is designated to test partial authorizations. Note that A05 Partially Approved response can be received under the condition if isPartialAuthorization field value is submitted as 1 and transactionIndustryType is submitted as either Retail or Restaurant, otherwise A01 Approved response is received.
***This range is designated to test chargebacks and reversals. In this scenario, the original transition is approved (A01 Approved is received in the response), but after a realtime transaction cycle is closed (batches settled for direct debit), a chargeback (for Z01 code) or chargeback and reversal is generated.
****This range is designated to test rejects. In this scenario, the original transition is approved (A01 Approved is received in the response), but after processing, the reject with D27 response code is generated.
*This range is designated to test rejects. In this scenario, A02 approval code is received in the response but after a realtime transaction cycle is closed (batches settled for direct debit), a reject is generated for transactions with the indicated amount range.
When working with test amount ranges, pay attention to the asterisks in the table below:
*D08/D21 response codes apply only in the cases when CSC/PIN code has been submitted. Otherwise, A01 Approved is returned.
**This range is designated to test partial authorizations. Note that A05 Partially Approved response can be received under the condition if isPartialAuthorization field value is submitted as 1 and transactionIndustryType is submitted as either Retail or Restaurant, otherwise A01 Approved response is received.
***This range is designated to test chargebacks and reversals. In this scenario, the original transition is approved (A01 Approved is received in the response), but after a realtime transaction cycle is closed (batches settled for direct debit), a chargeback (for Z01 code) or chargeback and reversal is generated.
****This range is designated to test rejects. In this scenario, the original transition is approved (A01 Approved is received in the response), but after processing, the reject with D27 response code is generated.
Note:
The amounts ending with 7 (for example, x.x7 dollars) are designated to test chargebacks. In this scenario, A01 approval code is received in the response, but after a realtime transaction cycle is closed, a chargeback is generated with Z02 code.
The amounts ending with 8 (for example, x.x8 dollars) are designated to test chargeback reversals. In this scenario, A01 approval code is received in the response, but after a realtime transaction cycle is closed, a chargeback reversal is generated with Z01 code.
The amounts ending with 7 (for example, x.x7 dollars) are designated to test chargebacks. In this scenario, A01 approval code is received in the response, but after a realtime transaction cycle is closed, a chargeback is generated with Z02 code.
The amounts ending with 8 (for example, x.x8 dollars) are designated to test chargeback reversals. In this scenario, A01 approval code is received in the response, but after a realtime transaction cycle is closed, a chargeback reversal is generated with Z01 code.
Sale/Sale-auth
| Amount Range | Payment Card | Direct Debit | |||
|---|---|---|---|---|---|
| In dollars | In cents | Response code | Response message | Response code | Response message |
| 70.00 – 74.99 | 7000 – 7499 | D01 | Denied by customer's bank | R01 | Insufficient Funds |
| 75.00 – 79.99 | 7500 – 7999 | D02 | Invalid Expiration Date | R02 | Account Closed |
| 75.00 – 79.99 | 7500 – 7999 | D02 | Invalid Expiration Date | R02 | Account Closed |
| 80.00 – 84.99 | 8000 – 8499 | D03 | Insufficient Funds | R03 | No Account |
| 85.00 – 89.99 | 8500 – 8999 | D04 | Hold - Pick up card | R04 | Invalid Account Number |
| 90.00 – 94.99 | 9000 – 9499 | D05 | Invalid card number | R05 | Unauthorized Debit to Consumer Account Using Corporate SEC Code |
| 95.00 – 99.99 | 9500 – 9999 | D06 | No account | R07 | Revoked Authorization |
| 100.00 - 104.99 | 10000 – 10499 | D08* | CSC is invalid | R10 | Advised as Unauthorized, Item is Ineligible, Notice not provided, Signatures not Genuine, or Item Altered, Improper Source Document, Amount of Entry not Accurately Obtained |
| 105.00 - 109.99 | 10500 – 10999 | D09 | Duplicate Transaction | R16 | Account Frozen |
| 110.00 - 114.99 | 11000 - 11499 | D10 | Card reported lost/stolen | R51 | Item is Ineligible; Notice not Provided; Signature Not Genuine; Item Altered; Amount of Entry not Accurately Obtained |
| 115.00 - 119.99 | 11500 - 11999 | D16 | Card is Expired | R99 | Transaction rejected by processor |
| 120.00 - 124.99 | 12000 - 12499 | D17 | Re-enter Transaction | ||
| 125.00 - 129.99 | 12000 - 12499 | D18 | Bad Amount | ||
| 130.00 - 134.99 | 13000 - 13499 | D21* | Pin Try Exceeded | ||
| 135.00 – 139.99 | 13500 – 13999 | D27 | Transaction Error | ||
| 140.00 – 144.99 | 14500 - 14999 | D29 | Card is restricted | ||
| 150.00 – 159.99 | 15000 – 15999 | A05** | Partially Approved | ||
| 160.00 – 169.99 | 16000 – 16999 | Z02*** | Chargeback received | ||
| 170.00 – 174.99 | 17000 - 17499 | D30 | Call for Authorization | ||
| 175.00 – 179.99 | 17500 - 17999 | D33 | Incorrect merchant setup | ||
| 180.00 – 184.99 | 18000 – 18499 | D41 | Processing Error | ||
| 185.00 – 189.99 | 18500 – 18999 | E02 | Processing Network Unavailable | ||
| 190.00 – 194.99 | 19000 – 19499 | Z01*** | Reversal received | ||
| 195.00 – 199.99 | 19500 – 19999 | D27**** | Transaction Error | ||
Credit (Credit Cards)
When working with test amount ranges, pay attention to the asterisks in the table below:*This range is designated to test rejects. In this scenario, A02 approval code is received in the response but after a realtime transaction cycle is closed (batches settled for direct debit), a reject is generated for transactions with the indicated amount range.
| Amount Range (in dollars) | Amount Range (in cents) | Response Code | Response Message |
|---|---|---|---|
| 90.00 – 94.99 | 9000 – 9499 | D05 | Invalid card number |
| 95.00 – 99.99 | 9500 – 9999 | D06 | No account |
| 135.00 – 139.99 | 13500 – 13999 | D27* | Transaction Error |
| 180.00 – 184.99 | 18000 – 18499 | D41 | Processing Error |
| 185.00 – 189.99 | 18500 – 18999 | E02 | Processing Network Unavailable |
Credit (Direct Debit)
Note that in scenarios below, the original transaction is approved (A02 Credit Posted code is returned), but after the realtime transaction cycle is closed, the return is generated.| Amount Range (in dollars) | Amount Range (in cents) | Response Code | Response Message |
|---|---|---|---|
| 75.00 – 79.99 | 7500 – 7999 | R02 | Invalid card number |
| 80.00 – 84.99 | 8000 – 8499 | R03 | No Account |
| 85.00 – 89.99 | 8500 – 8999 | R04 | Invalid Account Number |
| 115.00 – 119.99 | 11500 – 11999 | R99 | Transaction rejected by processor |
| Card Number | Track Data (SafeNet Luna encrypted) |
| 4111111111111111 | 029400850000000004160CE5C31E355F172C98994C142A49491B87DD2DAD5605A5394D111621706E21621602C9BAB1A9A0A1F8580604D5D9BB9B0D8CA3D90431373033629949003A0002E000E5760E03 |
| Card Number | Card Type | Account Data |
| 5413330089020110 | MasterCard | 4F07A0000000041010500A4D41535445524341524457115413330089020110D2512601079360805F820230008407A0000000041010950500000000009A031412309B02E8009C01005F2A0208405F3401039F02060000000015009F0607A00000000410109F090200029F10120210A00000000000000000000000000000FF9F120A4D6173746572436172649F1A0208409F1E0838303234373639329F21031107349F2608264E8FDAE6E596D69F2701809F3303E0B8C89F34034103029F3501229F360200019F37049B82EA999F3901059F4005F000F0A0019F4104000000139F530152 |
| 6510000000000141 | Discover | 4F07A00000015230105008444953434F56455257136510000000000141D16122011000071700000F5A0865100000000001415F200D434152442F494D4147452031345F24030812315F280208405F300202015F3401019F1A0208409F1E083830323437363932 |
| 4761739001010119 | Visa | 4F07A0000000031010500B564953412043524544495457114761739001010119D151220117589893895A0847617390010101195F201A56495341204143515549524552205445535420434152442030315F24031512315F280208405F300202015F3401019F120F4352454449544F20444520564953419F1A0208409F1E083830323437363932 |
| 374245001721009 | Amex | 4F08A0000000250108015010414D45524943414E20455850524553535713374245001721009D181020113101234500000F82025C008408A000000025010801950542800000009A031501199B02E8009C01005F2A0208405F3401009F02060000000015009F0608A0000000250108019F0902008C9F100706020103A400009F1A0208409F1E0838303234373639329F21032343539F2608F378EC2EA1C2B6AF9F2701809F3303E0B8C89F34034103029F3501229F360200019F370439D8850F9F3901059F4005F000F0A0019F4104000000179F530152 |
As part of testing, there may be a need to emulate the tokenization of card numbers. This can be done in two ways:
1) Using test card numbers. For this type of testing the host emulator is used. In this case, the scenario looks as follows:
2) Using live card numbers. For this type of testing a tokenization appliance is used. In this case, the scenario looks as follows:
1) Using test card numbers. For this type of testing the host emulator is used. In this case, the scenario looks as follows:
- a tokenization provider profile of the merchant/account that is going to be used for testing is set to proxy. See Creating a test provider profile tutorial for more information;
- test card numbers listed here are used;
- to emulate a general tokenization API call, the tokenization request can be submitted;
- to emulate a tokenization API call for HPP, the tokenization request via HPP can be submitted.
2) Using live card numbers. For this type of testing a tokenization appliance is used. In this case, the scenario looks as follows:
- a tokenization provider profile of the merchant/account that is going to be used for testing is set to StrongAuth or another tokenization appliance that the gateway is integrated with;
- live card numbers are used;
- to emulate a general tokenization API call, the tokenization request can be submitted;
- to emulate a tokenization API call for HPP, the tokenization request via HPP can be submitted.
As part of testing, the CSC codes specified below can be used to trigger specific CSC response codes from the server.
| CSC Code | CSC Response Code | Response Message |
| 111 | M | Matches |
| 222 | N | Not matches |
| 333 | P | Not processed |
| 444 | S | Should be present |
| 555 | U | Issuer is not certified |
As part of testing, there may be a need to emulate system behavior in cases when processing takes unusually longer time period as well as to verify the behavior in case of timeout of the platform being integrated with the gateway. In order to accomplish that, a delay directive has to be specified in the memo field according to the format below:
#wait[delay-period]x#, where
Using the tag described above it is possible to emulate the delay and timeout situations while working with either the host emulator or a processor’s test server. The following behavior should be expected from the system while testing these scenarios:
#wait[delay-period]x#, where
- #wait...# is a tag indicating to the emulator it is desired to have a processing delay;
- [delay-period] is a period in seconds for which processing is going to be delayed;
- x is an optional indicator, the presence of which will cause a timeout error at the end of the delay.
Using the tag described above it is possible to emulate the delay and timeout situations while working with either the host emulator or a processor’s test server. The following behavior should be expected from the system while testing these scenarios:
- Delay – the transaction will be delayed for processing for the indicated time period, meaning that after the timeout period has passed the transaction will get submitted for processing and an appropriate response will be returned back. Note that when the host emulator is used, the response will be generated according to the amount range specified in the API request. When the processor’s test server is used, the response will be generated according to the rules of that processor.
For example, to delay the response for 60 seconds, the memo field should be submitted as follows: memo=#wait60#. - Timeout – the transaction will be delayed for processing for the indicated time period, however, the transaction will not get submitted for subsequent processing and a timeout error response will be returned back.
For example, to delay the response for 180 seconds and receive a timeout, the memo field should be submitted as follows: memo=#wait180x#
Copyright ©
Constellation Payments. All Rights Reserved.
All Logos and Trademarks used or mentioned on this page are copyrighted property of their respective owners and are used for display purposes only.