Skip to content

Testing

Shabab Haider Siddique edited this page Jun 9, 2021 · 1 revision

You'll receive special Consumer Key and Consumer Secret for the testing environment. Endpoint URLs are the same as used in production. All the payments made in testing environment never hit real bank networks, so card is never charged.

Testing Cards

Basically you can use any valid VISA or MasterCard card number, however for your convenience we provide sample ones you can use:

Number Brand Test
4111111111111111 Visa *
4200000000000000 Visa 3D enrolled, authorization failed
4222222222222 Visa *
5555555555554444 MasterCard *
5454545454545454 MasterCard 3d enrolled, authorization passed

holder, exp_month, exp_year, cvc values can be set to any data you want. If those values passes validation and payment amount is less than 150.00 payment will be approved.

Test Cases

There is a variety of test cases which you can use to validate your integration with Cardinity payment processing gateway.

Successful Payment
  • create a valid payment with amount less than 150.00.
Failed Payment
  • status declined: Amount larger than 150.00 will trigger a declined payment e.g. 150.01.
  • incorrect pan: Use a number that fails the Luhn check, e.g. 4242424242424241.
  • invalid exp_month: Use an invalid month e.g. 13.
  • invalid_exp_year: Use a year in the past e.g. 1970.
  • invalid cvc: Use a two digit number e.g. 99.
  • invalid amount: Use less than 0.50 e.g. 0.49.
3D Secure Payment
  • create a valid payment with description attribute set to 3d-pass or 3d-fail (depending on the outcome you want).
  • response will be a payment in a pending state with authorization_information object provided.
  • afterwards finalize the payment (send a PATCH request) with authorize_data set to 3d-pass or 3d-fail.
  • the outcome of the 3D Secure authorization will be decided by authorize_data value sent.
Failed refund / void / settlement
  • set description attribute to fail.

test

Clone this wiki locally