Card Present

Process an In-Person Transaction

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: You must use vnAUS9x8h02stgcRCBv3Uw as the value for the payment.terminalId

NOTE: These scenarios use the POST operation against the /transactions/terminals resource and simulate a card being presented to the terminal device.

Simulate an Approved In-Person Transaction

Any amount value not listed in the declined scenarios will result in an approved payment. The result.status will return as approved. The result.codes array will contain a code and message indicative of the approval message returned by the card issuing bank. There are however a couple of specific approved scenarios you may wish to test.

Code	Message	Amount
A02000	approved	10000
A02008	honor_with_identification	10008
A02010	approved_for_partial_amount	10010
A02011	approved_vip	10011
A02016	approved_update_track_3	10016

Simulate a Declined In-Person Transaction

This scenario simulates a card being processed via the terminal device, but then declined by the customer’s bank. The result.status will return as declined. The result.codes array will contain a code and message indicating the reason for the decline.

Code	Message	Amount
D04401	refer_to_issuer	10001
D04402	refer_to_issuer_special	10002
D04403	no_merchant	10003
D04404	pick_up_card	10004
D04405	do_not_honor	10005
D04406	error	10006
D04407	pick_up_card_special	10007
D04409	request_in_progress	10009
D04412	invalid_transaction	10012
D04413	invalid_amount	10013
D04414	invalid_card_number	10014
D04415	no_issuer	10015
D04417	3d_secure_error	10017
D04419	reenter_last_transaction	10019
D04421	no_action_taken	10021
D04422	suspected_malfunction	10022
D04423	unacceptable_transaction_fee	10023
D04425	unable_to_locate_record_on_file	10025
D04430	format_error	10030
D04431	bank_not_supported_by_switch	10031
D04433	expired_card_capture	10033
D04434	suspected_fraud_retain_card	10034
D04435	card_acceptor_contact_aquirer_retain_card	10035
D04436	restricted_card_retain_card	10036
D04437	contact_aquirer_security_department_retain_card	10037
D04439	no_credit_account	10039
D04441	lost_card	10041
D04442	no_universal_account	10042
D04443	stolen_card	10043
D04451	insufficient_funds	10051
D04454	expired_card	10054
D04456	no_card_record	10056
D04457	function_not_permitted_to_cardholder	10057
D04459	suspected_fraud	10059
D04460	acceptor_contact_aquirer	10060
D04462	restricted_card	10062
D04463	security_violation	10063
D04464	original_amount_incorrect	10064
D04466	acceptor_contact_aquirer_security	10066
D04467	capture_card	10067
D04482	cvv_validation_error	10082
D04490	cut_off_in_progress	10090
D04491	card_issuer_unavailable	10091
D04492	unable_to_route_transaction	10092
D04493	cannot_complete_violation_of_the_law	10093
D04494	duplicate_transaction	10094
D04496	generate_system_error	10096

Modify an In-Flight Transaction

This scenario allows you to simulate the PATCH operations against the virtual terminal. To test this you will need to send a payment.amount value of 11010. This will introduce a 10 second delay between your submission of the transaction to the virtual terminal and the subsequent update of the transaction status to approved. During this time, you can do a PATCH operation to the /transactions/terminals endpoint to either cancel the transaction or simulate prompting for manual entry of the card.

Simulate a Declined Refund for an In-Person 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 return as declined. The result.codes array will contain a code and message indicating the reason for the decline.

Process a Omnichannel refund for an In-Person Transaction

An omnichannel In-Person refund can be done via the card target, which is processed online; instead of using a physical terminal device. This is suitable for cases when the cardholder is not present; and the merchant is initiating the refund on their behalf.

Steps

1. Process a successful transaction using either a virtual terminal or a physical terminal.
2. Submit a refund request using either the virtual terminal or a physical terminal.
   • Include "target": "card" in the request payload.
   • When this parameter is present, the terminalId field is not required and will be ignored (if provided).

Here is a refund sample request:

{
   "target": "card",
    "reference": "Invoice-123456",
    "amount": 100,
    "description": "Full client refund"
}

Notes

• Omnichannel refund availability can take up to 30 minutes after the transaction been processed.
• When using a virtual terminal to simulate a standalone refund in the sandbox environment, any amount value not listed in the Declined Scenarios table will result in an approved refund.
• In the sandbox environment, the card number used for the standalone refund may differ from the card used in the original in-person transaction.