Testing Web Payments - Card Payments

testing web payments card payments with judopay’s web payments solution, the 3d secure 2 flows are handled on your behalf for example, you will not see the conditional device details check step, as this occurs in the background it is useful to have an understanding of the full 3ds 2 payment flow, including the conditional steps, to verify how it relates to the user journey in your app for more information, see docid\ k7fnzbol73ssctbct4nxm when processing live transactions, in order to minimise declines we recommend setting the challengerequestindicator to challangeasmandate for more information on the different authentication flows, see docid\ saseq4ppwbnsjt if 0kx for checkcard requests, a challenge flow will always be forced, regardless of the challengerequestindicator flag setting the web payments card payment journey consists of the following steps select payment method enter billing information (optional) enter card details review and confirm (optional) you can customise whether to display the billing information and the review & confirm screens to the consumer during their payment journey card payment scenarios (positive flow) important to consider ensure the create web payment and retrieve web payment permissions are enabled on your api credentials ensure judopay has enabled 3d secure 2 on your sandbox tokens if 3d secure 2 is not enabled on your tokens, the test transaction will be successful, however it will not have followed the 3d secure 2 verification process contact mailto\ help\@judopay com to set this up ensure judopay has enabled the enforce avs checks on your sandbox tokens this will validate the billing address is registered to that card ensure you have set up the successurl and cancelurl landing pages in the judopay portal you can also contact mailto\ help\@judopay com to set this up if these are not set up a default landing page will be presented to the consumer the merchant will not have visibility of the transaction details and will need to create a get transaction query, or docid\ mqjiizxmcro1cpvauawud in order to be notified of the event you can determine which screens are displayed to the consumer during the payment flow set the hidebillinginfo and hidereviewinfo flags accordingly suggested test scenario process a web payments card payment / preauth / checkcard request with the billing information screen displayed to the consumer tip tip set the hidebillinginfo flag when creating the payment session create a web payment session where hidebillinginfo = false default setting = true the consumer is directed to the billing information screen during the payment flow expected outcome suggested test scenario process a web payments card payment / preauth / checkcard request with the review & confirm screen displayed to the consumer tip tip set the hidereviewinfo flag when creating the payment session the review & confirm screen will be hidden create a web payment session where hidereviewinfo = false default setting = true the consumer is directed to the review & confirm screen during the payment flow expected outcome suggested test scenario process a web payments card payment / preauth / checkcard request with the billing information screen hidden to the consumer tip tip set the hidebillinginfo flag when creating the payment session create a web payment session where hidebillinginfo = true default setting = true the consumer is directed to the pay with card screen, as the billing information screen is hidden during the payment flow expected outcome suggested test scenario process a successful web payments card payment and re direct to your successurl landing page tip tip ensure you have set up the successurl landing page in the judopay portal if this is not set up a default landing page will be presented to the consumer when re directing the post call to the successurl, the payload will also contain the receiptid cardtoken reference yourconsumerreference yourpaymentreference store the cardtoken for future transactions use the receiptid to get information on the transaction expected outcome suggested test scenario process a successful web payments card preauth and re direct to your successurl landing page tip tip ensure you have set up the successurl landing page in the judopay portal if this is not set up a default landing page will be presented to the consumer the send and download receipt buttons will be hidden as it is a preauth request expected outcome suggested test scenario process a successful web payments checkcard validation request and re direct to your successurl landing page tip tip ensure you have set up the successurl landing page in the judopay portal if this is not set up a default landing page will be presented to the consumer the checkcard request is similar to the payments and preauths request, just remove the amount field expected outcome suggested test scenario set an expiry date for the payment session tip tip the paymentsession will expire in 30 minutes , unless an expirydate is set in the /paymentsession request body update the expirydate field in the request body to set an expiry date in the future default = 30 minutes you can then store the session to use at a later date expected outcome "expirydate" "2028 11 05t16 28 32 8596+00 00", suggested test scenario cancel an open payment session tip tip update the status of an open payment session to cancelled, preventing it from being used in the future use the endpoint put /paymentsession/{reference}/cancel the reference returned in response to the creation of the payment session expected outcome }, "status" "cancelled", "transactiontype" "payment", }, suggested test scenario check the status of a payment session tip tip use the endpoint get /webpayments/{reference} the reference returned in response to the creation of the payment session possible status values open success expired cancelled you can determine the number of open attempts that are remaining for that payment session from the response the paymentsession can be used for up to three transaction attempts for the same transaction a payment session can be used again to re submit a failed transaction attempt once a transaction attempt is successful, the paymentsession can no longer be used even if there are any remaining attempts available the paymentsession will expire in 30 minutes , unless an expirydate is set in the /paymentsession request body expected outcome example 1 status open "status" "open", "transactiontype" "payment", "yourconsumerreference" "ab60f4e1 42a4 42e9 b2c5 6f1eb295f979", "yourpaymentmetadata" { "examplefield1" "value1", "examplefield2" "value2" }, "yourpaymentreference" "66c7c4ee 0888 48b3 9ac3 b6a63113f9cb", "webpaymentoperation" 0, "isjudoaccept" false, "isthreedsecuretwo" true, "noofauthattempts" 0, "mobilenumber" "7777777777", "phonecountrycode" "44", "emailaddress" "contact\@judopay com", "shortreference" "qoeewo" example 2 status expired "status" "expired", "transactiontype" "payment", "yourconsumerreference" "b4f34320 f3d5 4464 82df 335195f8d59d", "yourpaymentmetadata" { "examplefield1" "value1", "examplefield2" "value2" }, "yourpaymentreference" "4a04b9a2 fdbf 4ab2 b42d 5ff3a9016e1a", "webpaymentoperation" 0, "isjudoaccept" false, "isthreedsecuretwo" true, "noofauthattempts" 0, "mobilenumber" "7777777777", "phonecountrycode" "44", "emailaddress" "contact\@judopay com", "shortreference" "l8xek6" example 3 status success when you see status = success, the receiptid will also be in the response use the receiptid to get information on the transaction "status" "success", "transactiontype" "payment", "yourconsumerreference" "f5553f35 8826 49ff 894d 4522b52c9784", "yourpaymentmetadata" { "examplefield1" "value1", "examplefield2" "value2" }, "yourpaymentreference" "30ba117e 415d 4445 9114 8dc4d23846c7", "webpaymentoperation" 0, "isjudoaccept" false, "isthreedsecuretwo" true, "noofauthattempts" 1, "receipt" { "receiptid" "966323098188161024", }, example 4 status cancelled { "reference" "5qcaaaqaaaapaaaacaaaabtggvhbrf9bhtn7nqn1e0j4hvvmi y27dgpjwbmtls3gj xdg", "status" "cancelled" } for more information on api credentials and permissions, see docid\ s 8hoamytkgy13t0p657 card data to simulate a successful web payments request, use the docid obafnuc1umhk vihhs5d request parameters sandbox endpoint https //api sandbox judopay com/webpayments/preauths for the full schema details and descriptions, see https //docs judopay com/api reference/index html#/pre authorization/post transactions preauths sandbox endpoint https //api sandbox judopay com/webpayments/checkcard for the full schema details and descriptions, see https //docs judopay com/api reference/index html#/payment%20sessions/post webpayments checkcard sandbox endpoint https //api sandbox judopay com/webpayments/payments for the full schema details and descriptions, see https //docs judopay com/api reference/index html#/payment%20sessions/post webpayments payments 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 docid\ ylkw5coh5nqnfq3j wjk2 api version 6 23 for the latest version of the judopay transaction api, see 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 body parameters web payments configuration property descriptions parameter description judoid string required required unique id supplied by judopay specific to a merchant and/or location format 100100100 maximum length 9 characters do not include spaces or dashes amount decimal required required the amount to process format two decimal places for currencies using a different structure please contact judopay for support for checkcard requests, remove the amount field currency string required required the currency of the transaction any iso 4217 alphabetic currency code gbp usd eur phonecountrycode string optional optional the country code of the consumer's phone format maximum length 3 characters only numbers allowed do not include special characters or spaces yourconsumerreference string required required unique reference to anonymously identify your customer advisable to use guids must be below 40 characters yourpaymentreference string required required 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 cardaddress object optional optional card holder's address values address1 address2 (optional) town state (only required if country is usa/canada) country see docid\ xze369mfk5uvosanzm8uo for the list of valid iso 3166 1 format country codes postcode if the billingaddress is provided, the postcode is required mobilenumber string optional optional consumer’s valid mobile number format maximum length 15 characters only numbers allowed do not include special characters or spaces emailaddress string optional optional consumer’s valid email address it is recommended but not required for 3d secure 2 authentication primaryaccountdetails object optional optional this is mandatory for merchants who have an mcc code of 6012 , 6051 and 7299 primary account holder details name this is the surname accountnumber dateofbirth format yyyy mm dd postcode expirydate string optional optional date and time of expiry the default is 30 minutes from creation ispaybylink boolean optional optional flag indicating whether this session should be shown in the pay by link section in the judopay portal default = false isjudoaccept boolean optional optional flag indicating whether this session should be shown in the judo accept section in the judopay portal default = false successurl string optional optional this is the url to which the consumer is redirected if their transaction is successful if not set, then the default success url specified on your account is used format maximum length 2048 characters cancelurl string optional optional this is the url to which the consumer is redirected if they cancel the transaction or if the transaction fails if not set, then the default cancel url specified on your account is used format maximum length 2048 characters hidebillinginfo boolean optional optional this flag can be used to determine whether the 'billing information' page is shown on the webpayments ui default = true hidereviewinfo boolean optional optional this flag can be used to determine whether the 'review and confirm' page is shown on the webpayments ui default = true threedsecure object optional optional challengerequestindicator indicates the type of challenge request you wish to apply values nopreference nochallenge no challenge required challengepreferred a challenge is preferred for this transaction challengeasmandate must challenge this transaction scaexemption to apply for an exemption from sca, for a customer initiated transaction values lowvalue transactions up to €45 do not require sca, up to a maximum of five consecutive transactions, or a cumulative limit of €100 trustedbeneficiary provides the cardholder the option to add the merchant to their trusted list transactionriskanalysis allows for certain remote transactions to be exempt from sca, provided a robust risk analysis is performed web payments request example { "judoid" "yourjudoid", "yourconsumerreference" "yourconsumerreference", "yourpaymentreference" "yourpaymentreference", "yourpaymentmetadata" { "internallocationref" "example", "internalid" 99, "hidebackbutton" true }, "currency" "gbp", "amount" 12 99, "cardaddress" { "address1" "cardholder house", "address2" "1 cardholder street", "town" "cardholder town", "postcode" "ab1 2cd", "countrycode" 826, "state" "fl", "cardholdername" "john doe" }, "expirydate" "2028 02 05t16 28 32 8596+00 00", "ispaybylink" false, "isjudoaccept" false, "successurl" "https //my site com/success", "cancelurl" "https //my site com/cancel", "emailaddress" "test user\@judopay com", "mobilenumber" "7999999999", "phonecountrycode" "44", "threedsecure" { "challengerequestindicator" "challengeasmandate" }, "hidebillinginfo" true, "hidereviewinfo" true, "primaryaccountdetails" { "name" "doe", "accountnumber" "12345678", "dateofbirth" "1980 01 31", "postcode" "ab1 2cd" } } response example //store the reference returned in your backend server { "paybylinkurl" "https //pay sandbox judopay com/abc123", "posturl" "https //pay sandbox judopay com/v2", "reference" "5qcaaaqaaaapaaaacaaaabtggvhbrf9bhtn7nqn1e0j4hvvmi y27dgpjwbmtls3gj xdg" } card payment 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 process an unsuccessful web payments card payment / preauth and re direct to your cancelurl landing page use the following cardnumber 4221690000004963 cv2 452 expirydate 12/24 expected error code and description ensure you have set up the cancelurl landing page in the judopay portal if this is not set up a default landing page will be presented to the consumer the cardtoken value = null suggested negative test scenario process an unsuccessful web payments card checkcard validation request and re direct to your cancelurl landing page use the following cardnumber 4221690000004963 cv2 452 expirydate 12/24 expected error code and description ensure you have set up the cancelurl landing page in the judopay portal if this is not set up a default landing page will be presented to the consumer suggested negative test scenario attempt to perform a web payments card payment preauth request using an expired payment session expected error code and description 667003 webpayment reference is invalid suggested negative test scenario attempt to perform a web payments card payment preauth checkcard request using an invalid card number expected error code and description 196 unable to process transaction as the card number is invalid please try again with a different card suggested negative test scenario attempt to perform a web payments card payment preauth checkcard request using an invalid billing address 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 default setting = disabled expected error code and description 158 sorry, but your card authentication has failed suggested negative test scenario attempt to perform a web payments card payment preauth checkcard request using an expiry date that is in the past expected error code and description 155 sorry, but the web payment expiry date must be in the future suggested negative test scenario attempt to perform a checkcard request decline using the following cardnumber 4221690000004963 cv2 452 expirydate 12/24 expected error code and description 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 docid zrsihomuew xnrq4pbtj