What a card test refund is
A card test refund reverses a test charge in a payment provider sandbox. No real money moves. The refund uses the same test account, API key, and test card as the original charge. A test refund checks code paths for refunds, webhooks, ledgers, and error handling.
Do not use a live card or live key for a test refund. Live transactions create real authorization holds and real settlement records. Test mode isolates these records from production.
How to run a test refund
- Create a test charge with a provider test card number and a test CVV.
- Store the charge ID from the test response.
- Send a refund request for the full amount or a partial amount.
- Confirm the refund status in the test dashboard and API response.
- Replay the refund request to check idempotency and duplicate handling.
Use test amounts that match your production rules. For example, refund $10.00 from a $25.00 test charge. Check that the remaining $15.00 stays on the original charge. Partial refunds can exceed the original amount if code lacks limits. Test that case.
Refund states and errors
Test refunds can return states such as pending, succeeded, or failed. Providers define their own state names. A failed test refund can come from a bad charge ID, a closed test account, or a mismatched currency. Some providers reject refunds after a test charge expires. Check provider docs for expiry windows.
Records and reconciliation
A test refund should create a refund object, a webhook event, and a ledger entry in test mode. Compare the refund amount, currency, charge ID, and status. Do not store CVV data. PCI rules prohibit storage of the card verification value after authorization. Use test card data that the provider publishes.
If a test refund does not appear, check the API key mode, the charge ID, and the provider dashboard filter. Test mode and live mode use separate data sets. A refund created in live mode will not show in test mode.