Testing Web SDK - Card Payments

testing web sdk card payments with judopay’s web sdk solution, a minimal integration is all that is required to enable you to take a card payment take a card preauth take a card token payment take a card token preauth check the validity of a card, using checkcard prerequisites before attempting web sdk test transactions, ensure the following steps have been implemented docid 40dwe6lbub7vdkza1qydc docid 40dwe6lbub7vdkza1qydc defined the payment configuration , token configuration and check card configuration objects as required card payment scenarios (positive flow) important to consider yourpaymentreference is your unique reference for each transaction ensure you generate a unique yourpaymentreference and unique paymentsession for each transaction this will avoid duplicate transactions when making token payments, yourconsumerreference must match the original reference when the token was initially created ensure the following information in your configuration object(s) matches the information in the paymentsession judoid currency amount yourconsumerreference yourpaymentreference if this does not match, you will receive an error true 186,101,100 unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type for more information on api credentials and permissions, see docid\ s 8hoamytkgy13t0p657 test data to simulate a successful web payments request, use the docid obafnuc1umhk vihhs5d to trigger specific 3d secure 2 user journeys , include the cardholdername as specified in the docid\ bdcgiyqdm3mle ubxp1yr the cardholdername is case sensitive and corresponds to an expected transaction result request parameters taking a card payment or preauth define the configuration object for the payment or preauth add the invokepayment call to invoke a payment using the paymentsession and configuration object add the invokepreauth call to invoke a preauth using the paymentsession and configuration object making a check card request define the configuration object for the checkcard add the invokecheckcard call to make a check card request using the paymentsession and configuration object taking a card token payment or token preauth define the configuration object for the token payment or token preauth add the invoketokenpayment call to invoke a payment using the paymentsession and configuration object add the invoketokenpreauth call to invoke a preauth using the paymentsession and configuration object header parameters these header parameters are to be used when creating the docid\ a33b4pwt6brofejpghdh2 request to our transaction api for more information, see docid\ ylkw5coh5nqnfq3j wjk2 265,403 unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type body parameters web sdk payment / preauth / checkcard / token payment configuration parameter descriptions true 249 unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type request example const paymentconfiguration = { judoid "yourjudoid", amount 1 01, currency "gbp", phonecountrycode "44", challengerequestindicator "challengeasmandate", initialrecurringpayment false, yourconsumerreference "yourconsumerreference", yourpaymentreference "yourpaymentreference", billingaddress { address1 "my house", address2 "my street", town "my town", postcode "tr14 8pa", country "826" }, mobilenumber "07999999999", emailaddress "contact\@judopay com", primaryaccountdetails { name "doe", accountnumber "9999999", dateofbirth "1989 09 19", postcode "ab1 2cd" } } response example const onfulfillment = (receiptobject) => { const { result } = receiptobject //redirect to appropriate page depending on the result (success/failure/declined page) } const onrejection = (error) => { //redirect to error page and handle error } 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 true 284,98,100 unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type 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