Testing Merchant Initiated Transactions

testing merchant initiated transactions these scenarios do not include 3d secure 2 authentication testing see docid\ bdcgiyqdm3mle ubxp1yr for 3d secure 2 authentication testing for your app merchant initiated transactions (mit) scenarios (positive flow) the first subscription payment must have followed the 3d secure 2 flow contact mailto\ developersupport\@judopay com if you have any queries on initial mit payments see docid\ ek1dldo8cgr9di226zlyf for more information important to consider provide the following fields and associated values in your mit requests recurringpayment indicates if this is a recurring payment relatedreceiptid the receiptid returned from the first subscription payment must be as a result of the initial transaction being processed through a 3d secure 2 flow recurringpaymenttype indicates the type of recurring payment this can be set to 'recurring' (for scheduled payments) or 'mit' (for unscheduled payments) store the cardtoken and relatedreceiptid , as they will be required for future transactions the relatedreceiptid must be as a result of an initial transaction processed from a 3d secure 2 flow you need to tag your mit / recurring transactions correctly using the relatedreceiptid this is to ensure your transactions are not declined by your customers’ issuing bank the relatedreceiptid is the receiptid returned from the first subscription payment it references all subsequent recurring transactions to the original transaction following testing mit transactions in the sandbox environment, it is critical these are tested again with live transaction tests prior to formally going live , as sandbox behaviour differs slightly to live batch based mit tests due to rate limits applied in both sandbox and production, we recommend adding pauses between each mit batch transaction otherwise the quota limit may block transactions and cause undesirable results true 201,112,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 test card data to simulate a successful mit payment use the docid obafnuc1umhk vihhs5d mit request parameters sandbox endpoint https //api sandbox judopay com/transactions/payments sandbox endpoint https //api sandbox judopay com/transactions/preauths 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 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 unhandled content type unhandled content type unhandled content type unhandled content type body parameters configuration property descriptions true 214,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 mit request example { "cardnumber" 4111111111111111, "cv2" "838" "expirydate" "12/30", "cardaddress" { "address1" "cardholder house", "address2" "1 cardholder street", "town" "cardholder town", "postcode" "ab1 2cd", "countrycode" 826 }, "judoid" 100502814, "yourconsumerreference" "2b45fd3f cee5 4e7e 874f 28051db65408", "yourpaymentreference" "6482c678 cad3 4efd b081 aeae7a89a134", "yourpaymentmetadata" { "internallocationref" "example", "internalid" 99 }, "amount" 1 01, "currency" "gbp", "cardholdername" "john doe", "mobilenumber" 7999999999, "phonecountrycode" 44, "emailaddress" "test user\@judopay com", "shippingaddress" { "isbillingaddress" true }, "threedsecure" { "authenticationsource" "browser", "methodnotificationurl" "https //api sandbox judopay com/order/3ds/methodnotification", "challengenotificationurl" "https //api sandbox judopay com/order/3ds/challengenotification", "methodcompletion" false, "challengerequestindicator" "challengeasmandate" } } response example { "receiptid" "914568453493526528", "yourpaymentreference" "34a73594 f3b2 414c a5c9 58679530b418", "type" "payment", "result" "success", "judoid" 100502814, "originalamount" "5 00", "netamount" "5 00", "amount" "5 00", "currency" "gbp", "carddetails" { "cardlastfour" "1111", "enddate" "1230", "cardtoken" "sof xfmzmenor sj9mtrcvrxhw", "cardtype" 1, "cardscheme" "visa", "cardfunding" "credit", "cardcategory" "", "cardcountry" "us", "bank" "jpmorgan chase bank, n a " }, "cardaddress" { "address1" "cardholder house", "address2" "1 cardholder street", "town" "cardholder town", "postcode" "ab1 2cd", "countrycode" 826 }, "consumer" { "yourconsumerreference" "2b45fd3f cee5 4e7e 874f 28051db65408", }, } merchant initiated transactions (mit) 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 262,89,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 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