Testing Merchant Initiated Transactions

testing merchant initiated transactions 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 merchant initiated transactions (mit) scenarios (positive flow) the first subscription payment must have followed the 3d secure 2 flow contact developer support mailto\ developersupport\@judopay com if you have any queries on initial mit payments see merchant initiated transactions 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 false 201,112false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type test card data to simulate a successful mit payment use the test cards 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 authentication methods docid\ ylkw5coh5nqnfq3j wjk2 false false 265,403false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type body parameters configuration property descriptions true false 214false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type mit request example { "cardnumber" 4111111111111111, "cv2" "838" "expirydate" "01/25", "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" "1222", "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 false 262,89false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false 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 codes and descriptions docid zrsihomuew xnrq4pbtj