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	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	VD48963129999944441119	XVD01P0000000029832298045816474217001119
Debit	MasterCard	5149612222222229	0430	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^30041011000 1111A123456789012?	-
5499740000000057	%B5499740000000057^SMITH/JOHN^30041011000 1111A123456789012?	;5499740000000057=300410110000876?
6011000991001201	%B6011000991001201^SMITH/JOHN^30041011000 1111A123456789012?	-
371449635392376	%B371449635392376^SMITH/JOHN^30041011000 1111A123456789012?	-
4217651111111119	%B4217651111111119^SMITH/JOHN^30041011234567440?	;4217651111111119=30041011234567440?
5149612222222229	%B5149612222222229^SMITH/JOHN^30041011234567440?	;5149612222222229=30041011234567440?

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

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

Account Verification

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

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:

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.

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:

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