Testing your Integration
...
Testing Overview
Testing your Direct (API) Inte...
Testing RegisterCard
testing registercard we are no longer supporting or updating register card as it is an outdated method to verify cards, and is now deprecated check card is the recommended card verification method required by the card schemes these scenarios do not include 3d secure 2 authentication testing see testing 3d secure 2 authentication docid\ bdcgiyqdm3mle ubxp1yr for 3d secure 2 authentication testing for your app registercard scenarios (positive flow) registercard conducts a pre authorisation by reserving a pre configured amount in the customer's account the pre configured amount is set during your on boarding process ( the default amount is 1 01 ) registercard will tokenise the card information into an encrypted string, which can be used for future transactions the post /transactions/voids endpoint can be used to cancel this pre authorisation so it does not appear in the customer's statement important to consider registercard tests involve verification of the card cardnumber cardexpirydate cv2 the account is not blocked or blacklisted exists tokenises the card number into an encrypted string store yourconsumerreference and cardtoken and supply these in future card payment, preauth, or merchant initiated transaction requests a successful registercard request verifies the card with the issuer and can be authenticated using 3d secure 2, providing you with the confidence the card is valid to make future payments suggested test scenario expected outcome tip process a registercard request with the cv2/cvv security code included in the request this will check the cv2/cvv is valid for that card 200 successful the cv2 field check will be performed during the transaction process process a registercard request without the cv2/cvv security code included in the request declined the cv2 field check will not be performed during the transaction process process a registercard request with the billing address information (cardaddress block) included in the request this will validate the billing address is registered to that card 200 successful ensure the cardaddress block has the correct fields address1 address2 town postcode required countrycode see country codes docid\ xze369mfk5uvosanzm8uo for the list of valid iso 3166 1 format country codes example cardaddress block "cardaddress" { "address1" "cardholder house", "address2" "1 cardholder street", "address3" "cardholder area", "town" "cardholder town", "postcode" "ab1 2cd", "countrycode" 826, "state" "fl", }, to validate the card is registered to the correct post code, ensure the following permission on your sandbox api credentials is enabled enforce avs checks the default setting = disabled process a registercard request without the billing address information (cardaddress block) included in the request 200 successful for more information on api credentials and permissions, see introduction docid\ s 8hoamytkgy13t0p657 test card data to simulate a successful registercard request use the test cards docid obafnuc1umhk vihhs5d register card request parameters sandbox endpoint https //api sandbox judopay com/transactions/registercard http method post header parameters depending on how you integrate with judopay, you can authenticate requests by /paymentsession , or tokensecretauth the token and secret pair for more information, see authentication methods docid\ ylkw5coh5nqnfq3j wjk2 api version 6 22 for the latest version of the judopay transaction api, see transaction api reference docid\ bcxnm5keok nlnrztafut content type application/json accept application/json authorization method tokensecretauth in the authorization header supply basic { authstring } example basic txpfdpdrszwmsgk4djhxetpjbts4yjq5otdkzmo7ctk1yte0oweymdg1mmy3ywyyzweyztcwymqyzgy3o replace { authstring } with base64 encoding of api token api token (username) colon colon api secret (password) example mzpdkqk1mgi8v3ky mzpdkqk1mgi8v3ky y158n4732dfc7595a149a20381f7af2ea2e70gr6df794b8rnwc019cc5f799kk3 authorization method paymentsessionauthtoken for payment session authentication in the api token header supply the token used to authenticate the call to generate a payment session the payment session header value must also be supplied authorization method paymentsessionauthreference for payment session authentication in the payment session header supply the reference returned in the create payment session response the api token header value must also be supplied body parameters configuration property descriptions parameter description judoid string optional optional unique id supplied by judopay specific to a merchant and/or location format 100100100 maximum length 9 characters do not include spaces or dashes cardnumber string required required the unique number printed on the card (13 to 19 digits depending on card type) submitted without whitespace or non numeric characters expirydate string required required the expiry date of the card format mm/yy cv2 string optional optional the 3 or 4 digit number on the back of the card also known as the card verification value (cvv) or security code yourconsumerreference string required required unique reference to anonymously identify your customer advisable to use guids must be below 40 characters yourpaymentreference string optional optional your unique reference for this payment format maximum length 50 characters this value should be unique in order to protect your customers against duplicate transactions with a server side integration, if a payment reference is not supplied, the transaction will not be processed cardholdername string optional optional the full name of the card holder register card request example { "yourconsumerreference" "testcustomer\@example com", "yourpaymentreference" "5312b7b1 e89c 4155 971a 6e6fa3fb1e26", "judoid" "100873697", "cardnumber" "4976000000003436", "expirydate" "12/24", "cv2" "452", "cardholdername" "lonnie rath v" } response example { "receiptid" "955140933322228704", "yourpaymentreference" "5312b7b1 e89c 4155 971a 6e6fa3fb1e26", "type" "register", "createdat" "2023 03 20t16 29 07 8907+00 00", "result" "success", "message" "authcode 852549", "judoid" 100042597, "merchantname" "shodan ai routing", "appearsonstatementas" "apl /shodanairouting ", "originalamount" "1 01", "netamount" "1 01", "amount" "1 01", "currency" "gbp", "acquirertransactionid" "02448183756786407808", "externalbankresponsecode" "", "authcode" "852549", "carddetails" { "cardlastfour" "3436", "enddate" "1224", "cardtoken" "sof vjssceeee4adidgqfqpijg", "cardtype" 11, "cardscheme" "visa", "cardfunding" "debit", "cardcategory" "classic", "cardqualifier" 0, "cardcountry" "fr", "bank" "credit industriel et commercial", "cardholdername" "lonnie rath v" }, "consumer" { "consumertoken" "qlydgbomqgmswqgd", "yourconsumerreference" "testcustomer\@example com" }, "threedsecure" { "attempted" false }, "risks" { "postcodecheck" "unknown", "cv2check" "passed", "merchantsuggestion" "allow" } } registercard scenarios (negative flow) declines can occur for various reasons, it can be impossible to simulate all the negative flows in a sandbox environment important to consider how your app handles negative flows your customer's experience should a negative flow occur logic to communicate error messages customise how your app responds how to maintain application consistency follow our suggested guidelines to simulate negative scenarios, to test your app’s error handling suggested negative test scenario expected error code error description attempt to perform a registercard request using an invalid card expiry date 161 sorry, but the card expiry date must be in the future attempt to perform a registercard request using an invalid card number 196 unable to process transaction as the card number is invalid please try again with a different card attempt to perform a registercard request with an invalid cv2 74 the cv2 entered is invalid attempt to perform a registercard request with a missing cv2 the sandbox token has cv2 enabled, the registercard request has an empty cv2 field sorry, you've not supplied the 3 digit card security code please check your details and try again this is a codes and descriptions docid zrsihomuew xnrq4pbtj simulate a decline using the following test card details attempt to perform a registercard decline using the following cardnumber 4221690000004963 cv2 452 expirydate 12/24 declined card declined where the codes remain fixed, the descriptions may change you should not build any error handling logic based on these descriptions for a list of possible error codes, types and descriptions, see codes and descriptions docid zrsihomuew xnrq4pbtj next steps using the yourconsumerreference and cardtoken from the successful registercard response, you can test the following scenarios testing card preauths docid\ gwwuvrkwonc5yvk6qhmmi testing card payments docid\ nq7c98panemfgukhbpucb testing merchant initiated transactions docid\ gb1c oqbh7uuw8rzusawt