Real Time (HTTPs) APIs

Integration




Integration Overview 

The integration within the gateway can be tested using data presented below.

Test Cards and Bank Accounts 

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 0422 VC84632147254611111111 XVC01P0000000084632147254611114111001111
Credit MasterCard 5499740000000057 0422 MC32541698745800570057 XMC01P0000000032541698745800575499000057
Credit Discover 6011000991001201 0422 DC65874123589012011201 XDC01P0000000065874123589012016011001201
Credit Amex 371449635392376 0422 AC21548730012123762376 XAC01P0000000021548730012123763714002376
Debit Visa 4217651111111119 0422 VD48963129999944441119 XVD01P0000000029832298045816474217001119
Debit MasterCard 5149612222222229 0422 MD57543852138455552229 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

Track Data (unencrypted) 

Card Number Track Data 1 Track Data 2
4111111111111111 %B4111111111111111^SMITH/JOHN^22041011000 1111A123456789012? -
5499740000000057 %B5499740000000057^SMITH/JOHN^22041011000 1111A123456789012? ;5499740000000057=220410110000876?
6011000991001201 %B6011000991001201^SMITH/JOHN^22041011000 1111A123456789012? -
371449635392376 %B371449635392376^SMITH/JOHN^22041011000 1111A123456789012? -
4217651111111119 %B4217651111111119^SMITH/JOHN^22041011234567440? ;4217651111111119=22041011234567440?
5149612222222229 %B5149612222222229^SMITH/JOHN^22041011234567440? ;5149612222222229=22041011234567440?

Track Data (ID Tech encrypted) 

Card Number Track Data (ID Tech encrypted)
4111111111111111 021301000F3D0000%*4111********1111^SMITH/JOHN^*****************************?*8D40AD26E14C98F73B0210CD5F18A62ACF2B655EABC19BC10DAEEB870B42D6EADC20CE84E3677286B56D6F1CB7C4276C6BF10A91DB9E5947CA68AFD5884C2737312165237673628FB321C9B5F5094594C71F123CE8980E3482F3CB89629949003A0002E000E759D903
5499740000000057 029E01001F3D2300%*5499********0057^SMITH/JOHN^*****************************?*;5499********0057=***************?*89FCA5568C70B2C2B5D6C7340477F04703FA30BBEA5F82136611223413CE3720C2A32D8F874CC20DAB29759BFA635B822500C752A268B3A2F2303670908139B92920E329AF65DAA1AEDE885E737D06F160B0E4FCBFFF371E3539E9F90203AE0E577EF4E5E989DBD2F078ED378E00CE41BAA7126E3371A660916AE85EFE29841ACB519F88D287E4DE3DBACFDD0B01830C629949003A0002E000E860AC03
6011000991001201 021301000F3D0000%*6011********1201^SMITH/JOHN^*****************************?*D98ED1922DD71C873885B03FA51FBA0D72C71CE483E5CD0E5D024ECBE6F7059B590C5FF806FAAA8A71500B4011FDF9C197600E8FF0A46322DF3E33D725BEA0FE5AF418E3421F74B9BC215A971369E0D9A04B7157C1299B31A267A483629949003A0002E000E658D803
371449635392376 021201000F3C0000%*3714*******2376^SMITH/JOHN^*****************************?*85A604DCC61A4548C742B83417F3ECB604AF3952D02D4D86DCB264DB0E329C5C59827EE94F31D1798285F4680A275EA967E462F3D487C1A91C5C2BF286A8E31AF5BF7A9FC3D56824AB7241A63DAC255591800651724EA2BD453C0132629949003A0002E000EB757303
4217651111111119 028401001F312500%*4217********1119^SMITH/JOHN^*****************?*;4217********1119=*****************?*5CD5835110BF4E86EDE238BB904347E7A3B161D268B632B813A5C481837AFA7CC12F9AC164CFA5776C2FEE6A8604AAE5CE82A8A53B5774B8DA613625BD019D1719B3A149B9346751A350E12BC3A4563C466F8A10DB42A505A64F72FA0E12CD4873471536B6319D6E6E74C932066AB177CF398290C362743A2FDB432F0BEBB71D0F9CFAF3B9C0F8AE629949003A0002E000EA683803
5149612222222229 028401001F312500%*5149********2229^SMITH/JOHN^*****************?*;5149********2229=*****************?*D905659FD3CDCF075B516FCC7011B0C9B2CB914D19C1D998D6AD029FB5ED17EF64323354FDAFA93C777FD15E124DBAC546D23DB9EB2E519146484D0832E698E2387689EF48AC80F9F6345F36295C3F66CF6641D1B526D6B9CA0A8047A77EA6ECE1F10528C667CD0D6E6637514AE9F53162A7495BA6AAE8BA0A5CFF2DD2F7E8BE0B1238445EE1A4EE629949003A0002E000E9170D03
4119979004197914 * 0294008500000000041672ACD19462FA24B62E93FD92EFB2B5B44169313104F709995D40F2528FF8B664AE32CB0353D4479A904C6AB7042BEF135EDE34210432303033629949003A0002E000EE7F3703
*Manually entered track data

Track Data (SafeNet Luna encrypted) 

Card Number Track Data (SafeNet Luna encrypted)
4111111111111111 029400850000000004160CE5C31E355F172C98994C142A49491B87DD2DAD5605A5394D111621706E21621602C9BAB1A9A0A1F8580604D5D9BB9B0D8CA3D90431373033629949003A0002E000E5760E03

EMV Data Samples 

Card Number Card Type Account Data
5413330089020110 MasterCard 4F07A0000000041010500A4D41535445524341524457115413330089020110D2512601079360805F820230008407A0000000041010950500000000009A031412309B02E8009C01005F2A0208405F3401039F02060000000015009F0607A00000000410109F090200029F10120210A00000000000000000000000000000FF9F120A4D6173746572436172649F1A0208409F1E0838303234373639329F21031107349F2608264E8FDAE6E596D69F2701809F3303E0B8C89F34034103029F3501229F360200019F37049B82EA999F3901059F4005F000F0A0019F4104000000139F530152
6510000000000141 Discover 4F07A00000015230105008444953434F56455257136510000000000141D16122011000071700000F5A0865100000000001415F200D434152442F494D4147452031345F24030812315F280208405F300202015F3401019F1A0208409F1E083830323437363932
4761739001010119 Visa 4F07A0000000031010500B564953412043524544495457114761739001010119D151220117589893895A0847617390010101195F201A56495341204143515549524552205445535420434152442030315F24031512315F280208405F300202015F3401019F120F4352454449544F20444520564953419F1A0208409F1E083830323437363932
374245001721009 Amex 4F08A0000000250108015010414D45524943414E20455850524553535713374245001721009D181020113101234500000F82025C008408A000000025010801950542800000009A031501199B02E8009C01005F2A0208405F3401009F02060000000015009F0608A0000000250108019F0902008C9F100706020103A400009F1A0208409F1E0838303234373639329F21032343539F2608F378EC2EA1C2B6AF9F2701809F3303E0B8C89F34034103029F3501229F360200019F370439D8850F9F3901059F4005F000F0A0019F4104000000179F530152

Test Amount Ranges 

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:
*This range is designated to test voice authorization. Sale/sale-auth transaction with the amount that equals to $90.00-99.99 results in D30 decline code, however, if the approvalCode field value is specified as 012345 within the request, A01 approval code is received.
**This range is designated to test partial authorizations. When a sale transaction with this amount range is submitted, it is approved partially. Approved amount is $10 less than the originally requested amount. 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 D03 Insufficient Funds response is received.
***This range is designated to test chargebacks. In this scenario, A01 approval code is received in the response but after a cycle is closed (batches settled for direct debit), a chargeback is generated for transactions with the indicated amount range.
****This range is designated to test chargeback reversals. In this scenario, A01 approval code is received in the response but after a cycle is closed (batches settled for direct debit), a chargeback reversal is generated for transactions with the indicated amount range.
*****This range is designated to test rejects. In this scenario, A01 approval code is received in the response but after a cycle is closed (batches settled for direct debit), a reject is generated for transactions with the indicated amount range.

Sale/Sale-auth

Amount Range Payment Card Direct Debit
In dollars In cents Response code Response message Response code Response message
5.00 – 69.99 500 – 6999 A01 Approved A01 Approved
70.00 – 79.99 7000 – 7999 D05 Invalid card number R05 Unauthorized debit to consumer using corporate sec code
80.00 – 89.99 8000 – 8999 D10 Card reported lost/stolen R02 Account closed
90.00 – 99.99 9000 – 9999 D30* Call for Authorization* R08 Stop payment or stop on source document
100.00 – 109.99 10000 – 10999 D04 Hold - Pick up card R16 Account frozen
110.00 – 119.99 11000 - 11999 D08 CSC is invalid R03 Unauthorized debit to consumer using corporate sec code
120.00 – 129.99 12000 – 12999 D03 Insufficient Funds R01 Insufficient Funds
130.00 – 139.99 13000 – 13999 E02 Processing Network Unavailable E02 Processing Network Unavailable
140.00 – 149.99 14000 – 14999 D41 Processing Error D41 Processing Error
150.00 – 159.99 15000 – 15999 A05** Partially Approved** A01 Approved
160.00 – 169.99 16000 – 16999 D24*** Chargeback received*** A01 Approved
300.00 – 1500.00 30000 – 150000 A01 Approved A01 Approved
1600.00 – 1609.99 160000 – 160999 A12**** Reversal received**** A01 Approved
1700.00 – 1799.99 17000 – 17999 D27***** Transaction Error***** A01 Approved

Credit

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, A01 approval code is received in the response but after a 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
5.00 – 69.99 500 - 6999 A02 Credit Posted
1700.00 – 1709.99 170000 – 170999 D27* Transaction Error*

Account Verification 

As part of testing, the ZIP codes specified below can be used to trigger specific response codes from the server. To trigger the respective account verification responses, the combination of 4111111111111111 card number and an associated expiration date must be used.

ZIP Code Response Code Response Message
11111 A01 Approved
55555 D05 Invalid card number (Invalid Account Number)
00010 D10 Card reported lost/stolen (Lost/Stolen Card)
00001 D01 Denied by customer's bank (Do Not Honor)
88888 D08 CSC is invalid (Decline CSC/CID Fail)

AVS Verification 

As part of testing, the ZIP codes specified below can be used to trigger specific AVS response codes from the server.

ZIP Code AVS Response Code Response Message
11111 00 AVS Error - Retry, System unavailable or Timed out
22222 46 Street address doesn't match, 5-digit ZIP matches
33333 43 Street address not available (not verified), ZIP matches
44444 40 Address failed
55555 4F Street address and ZIP match

Tokenization 

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:
  • 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.

PIN Debit 

As part of testing, the PIN and DUKPT values specified below can be used to test PIN Debit transactions. To receive a test BDK key that has to be injected into a terminal or a PIN pad, please contact gateway support team.

PIN DUKPT
817DE116BA45CEDB F8765432100000000002
BCE8BA66CFE24CCF F8765432100000000003

CSC Verification 

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

Balance Inquiry 

As part of testing, an expiration date with the month values specified below can be used to trigger a specific response as a result of a balance inquiry operation.

Month Balance Amount (in dollars) Balance Amount (in cents)
01 100 10000
02 10 1000
12 0 0

Bank Identifier (BIN) 

As part of testing, the month value of the expiration date can be used to trigger specific information associated with a particular BIN. To trigger the respective card type and issuing bank country responses, the combination of 4111111111111111 card number and an associated expiration date must be used.

Month Card Type Issuing Bank Country
01 Credit US Issued
02 Credit Canada Issued
03 Credit UK Issued
04 Regulated Debit US Issued
05 Non-Regulated Debit US Issued
06 Non-Regulated Debit Canada Issued
07 Non-Regulated Debit UK Issued

Processing Delay 

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
  • #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 (proxy) 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 (proxy) 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. When the host emulator is used, the returned response code is E02 (Processing Network Unavailable).
    For example, to delay the response for 180 seconds and receive a timeout, the memo field should be submitted as follows: memo=#wait180x#

Recurring Transactions 

As part of testing, an integrator can verify a correct implementation of the stored credentials logic (submission of the networkTransactionId field). This logic is available for Visa cards only, because of that you have to use a Visa card and submit a sale or sale-auth transaction to cause the emulator to generate the networkTransactionId field value in a response.

To emulate a typical scenario, you can generate several sale/sale-auth transactions:
  1. In the first transaction, the sequenceNumber field value has to equal to 1. When the first transaction with Visa card is submitted, the networkTransactionId field is generated in the response.
  2. In the subsequent transactions, the following values have to be submitted:
  • sequenceNumber - has to be incremented by 1 every time a new transaction is generated (e.g. 2, 3, 4, 5);
  • amount - equals the amount of the first transaction;
  • originalNetworkTransactionId - equals to the networkTransactionId received in the first transaction or, for recurring transactions, in the previous one.

If the originalNetworkTransactionId and amount field values in a subsequent transaction have been submitted as described above, the transaction is approved. If you specify as a value of networkTransactionId something random and not the value generated by the gateway in previous transactions, you will get a decline. The transactions will also get declined if the amount of the current transaction differs from the amount of the original transaction that you are referencing through a networkTransactionId field.

Note that the host emulator generates the networkTransactionId field value by concatenation of the sequenceNumber and amount field values. Be advised that this algorithm is specific to the host emulator only and does not reflect the way that the networks generate respective values. Please do not rely on the structure of this value in any way.