Skip to content

Payto

This article describes the different scenarios that can be simulated in the Sandbox environment. The payment.amount field is used to control the desired behaviour.

NOTE: These scenarios use the POST operation against the /transactions resource. You must have already created a customer token with a payment agreement as the payment instrument.

Any amount value not listed in the below scenarios will result in an approved payment. The result.status will change from pending to approved and you will receive a webhook notification with the updated status. The result.codes array will return an A10000 result code.

This scenario simulates a payto transaction being submitted, but then declined by the customer’s bank. The result.status will change from pending to declined and you will receive a webhook notification with the updated status. The result.codes array will contain a code and message indicating the reason for the decline.

Code Message Amount
D10001 target_account_invalid 11001
D10002 target_account_blocked 11002
D10003 from_account_closed 11003
D10004 amount_invalid 11004
D10014 target_account_unreachable_for_credits 11005
D10015 amount_below_minimum 11006
D10016 amount_above_maximum 11007
D10018 receiving_bank_unavailable 11008
D10019 amount_invalid_for_payment_agreement 11009
D10020 payment_agreement_max_transactions_exeeded 11010
D10021 payment_agreement_max_amount_exeeded 11011
D10023 porting_unavailable 11013
D10024 insufficient_funds 11014
D10030 payid_cancelled 11012

Simulate a Declined Refund for a PayTo Transaction

Section titled “Simulate a Declined Refund for a PayTo Transaction”

This scenario simulates a refund being submitted and getting declined by the customer’s bank. To simulate a failed refund, use the payment.amount values from the table above. The result.status will change from pending to declined and you will receive a webhook notification with the updated status. The result.codes array will contain a code and message indicating the reason for the decline.