Skip to main content

Test based payment flows

To give merchants a consistent payment experience, you must test and verify your app integration.

The test scenarios include steps to make sure your integration processes transactions correctly.

Test #1: Sale without tipping prompt and signature prompt​

  1. (POS) Create a sale request of the amount.
  2. (CodePay) Swipe a test card number.

The sale is processed without any tipping option and signature prompt.

Test #2: Cancel a transaction​

  1. (POS) Select the transaction from test #1.
  2. (CodePay) Cancel the full amount of the sale.

The cancel is complete. The transaction was voided

Test #3: Sale without tipping prmopt but with signature prmopt​

  1. (POS) Create a sale request of the amount.
  2. (CodePay) Swipe a test card number.
  3. (CodePay) On the signature screen, draw a name and tap Done.

The sale is processed without any tipping option.

Test #4: Tip adjustment​

  1. (POS) Select the transaction from test #3 and adjust the tip amount.
  2. (CodePay) The transaction total is updated to include the tip.

Test #5: Batch close​

  1. (POS) Create a batch close request.
  2. (CodePay) Close the current batch of transactions.

Test #6: Refund a referenced transaction​

  1. (POS) Select the transaction from test #3 that was settled.
  2. (CodePay) Refund the full amount of the sale.

Test #7: Refund a unreferenced transaction​

  1. (POS) Create a refund request of the amount.
  2. (CodePay) Swipe any test card number.
  3. (CodePay) Refund the amount entered in the POS.

Failure and recovery scenarios​

A real integration also has to handle transactions that don't go smoothly. Test these scenarios using the test cards for specific responses before you go live.

Test #8: Declined sale​

  1. (POS) Create a sale request of the amount.
  2. (CodePay) Swipe the Decline test card for your card brand.

The sale is declined. Your app shows the decline to the cashier/customer and does not treat it as a successful payment.

Test #9: Timeout / unknown result​

  1. (POS) Create a sale request of the amount.
  2. (CodePay) Swipe the Timeout test card for your card brand.

Your app should not assume the sale failed. Instead of retrying with a new order, call Query order using the same merchant_order_no to confirm the final result.

Test #10: Duplicate order number​

  1. (POS) Create a sale request using a merchant_order_no that already belongs to a completed transaction.
  2. (CodePay) Swipe any test card number.

The second request is rejected with E04112 ("Merchant order number repeat") — that rejection is not the transaction result. Your app should call Query order with the same merchant_order_no to retrieve the original outcome, instead of showing the rejection as a failed payment or resubmitting under a new order number.

Test #11: Terminal offline or unreachable​

  1. (POS) Disconnect the terminal from the network (or turn off ECR Hub), then create a sale request.

Your app should detect the failed connection and show a clear error instead of leaving the cashier waiting or assuming the sale went through. Reconnect the terminal and confirm normal sales resume.

Test #12: Missed payment notification​

  1. (POS) Create a sale request through the cloud API, but stop your backend from acknowledging the notify_url callback (for example, take the endpoint offline or return an error).
  2. (CodePay) Swipe a test card that approves the sale.

Your backend never receives a usable notification. Confirm your polling fallback (see Verify payment results reliably) still detects the completed payment and updates the order.