Testing Refunds

testing refunds card refund scenarios (positive flow) important to consider ensure the refund payments permission is enabled on your api credentials ensure you have the correct receiptid for the original payment or collection this is required for you to process the refund you can make multiple partial refund requests, up to the original transaction amount these scenarios can be used on card apple pay™ google pay™ test transactions to simulate a full or partial refund on the original transaction amount true false 251,149false 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 request parameters sandbox endpoint https //api sandbox judopay com/transactions/refunds http method post header parameters 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 body parameters ensure you have the correct receiptid for the original transaction to process the full or partial refund configuration property descriptions true false 243false 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 refund request example { "receiptid" "675014982672486400", "amount" 10 99, "currency" "gbp", "yourpaymentreference" "6482c678 cad3 4efd b081 aeae7a89a134" } response example { "receiptid" "914572343442046976", "originalreceiptid" "914572313402441728", "yourpaymentreference" "9b3855ae cae6 4342 a503 2908e3a1593f", "type" "refund", "createdat" "2022 11 28t17 43 58 9941+00 00", "result" "success", "message" "refund successful", "judoid" 100502814, "merchantname" "shodan cybersource routing", "appearsonstatementas" "apl /shodancybersourcero", "originalamount" "5 00", "netamount" "0 00", "amount" "5 00", "currency" "gbp", "acquirertransactionid" "7016975398", "externalbankresponsecode" "", "carddetails" { "cardlastfour" "1111", "enddate" "1222", "cardtoken" "endper5kpglawedhdj3lzkj5zecqpr4s", "cardtype" 1, "cardscheme" "visa", "cardfunding" "credit", "cardcategory" "", "cardcountry" "us", "bank" "jpmorgan chase bank, n a " }, "consumer" { "yourconsumerreference" "cardswithmultipleconsumers2" } } card refund 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 272,117false 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 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