Test Stripe Terminal

Learn how to effectively test your Terminal integration.

Much of the process for testing Stripe Terminal is similar to that for testing online Stripe payments. Refer to the general Stripe testing guide for more information.

The best way to achieve a successful Terminal deployment is to test every part of your integration. We provide testing tools for each stage:

Before ordering a reader, test your integration with the reader simulator.
Test your complete hardware integration with a physical test card.

Simulated reader

The Stripe Terminal SDK comes with a built-in simulated card reader, so you can develop and test your app without connecting to physical hardware. Whether your integration is complete or you’re just starting out, use the simulated reader to emulate all the Terminal flows in your app.

Note that the simulated reader does not provide a UI. After connecting to it in your app, you can see it working when calls to the Stripe SDK succeed.

Simulated test cards

The simulated reader can be configured to use a simulated test card, enabling you to test different flows within your point of sale application.

Before collecting a payment method, configure the simulated reader to use one of the following test card numbers or test payment methods to produce specific responses.

Standard test cards

Test Card Number	Test Payment Method	Brand
	`visa`	Visa
	`visa_debit`	Visa (debit)
	`mastercard`	Mastercard
	`mastercard_debit`	Mastercard (debit)
	`mastercard_prepaid`	Mastercard (prepaid)
	`amex`	American Express
	`amex2`	American Express
	`discover`	Discover
	`discover2`	Discover
	`diners`	Diners Club
	`diners_14digits`	Diners Club (14 digit card)
	`jcb`	JCB
	`unionpay`	UnionPay
	`interac`	Interac

Test cards for specific success cases

Test Card Number	Test Payment Method	Result
	`offline_pin_cvm`	Simulates the cardholder being prompted for and entering an offline PIN. The resulting charge has cardholder_verification_method set to `offline_pin`.
	`offline_pin_sca_retry`	Simulates an SCA-triggered retry flow where a cardholder’s initial contactless charge fails and the reader then prompts the user to insert their card and enter their offline PIN. The resulting charge has cardholder_verification_method set to `offline_pin`.
	`online_pin_cvm`	Simulates a cardholder being prompted for and entering an online PIN. The resulting charge has cardholder_verification_method set to `online_pin`.
	`online_pin_sca_retry`	Simulates an SCA-triggered retry flow where a cardholder’s initial contactless charge fails and the reader then prompts the user to input their online PIN. The final charge has cardholder_verification_method set to `online_pin`.

Test cards for specific error cases

Test Card Number	Test Payment Method	Result
	`charge_declined`	Charge is declined with a `card_declined` code.
	`charge_declined_insufficient_funds`	Charge is declined with a `card_declined` code. The decline_code attribute is `insufficient_funds`.
	`charge_declined_lost_card`	Charge is declined with a `card_declined` code. The decline_code attribute is `lost_card`.
	`charge_declined_stolen_card`	Charge is declined with a `card_declined` code. The decline_code attribute is `stolen_card`.
	`charge_declined_expired_card`	Charge is declined with an `expired_card` code.
	`charge_declined_processing_error`	Charge is declined with a `processing_error` code.
	`refund_fail`	Charge succeeds but refunding a captured charge fails asynchronously with a `failure_reason` of `expired_or_canceled_card`. Note that because refund failures are asynchronous, the refund will appear to be successful at first and will only have the `failed` status on subsequent fetches. We also notify you of refund failures using the `charge.refund.updated` webhook event. This simulated error is only supported in the JavaScript SDK.

Physical test cards

Test payments with your Stripe Terminal reader using a physical test card. You can purchase readers and physical test cards from the Terminal tab of the Stripe Dashboard.

This physical test card supports both chip entry and contactless payments. It only works with Stripe’s pre-certified readers, and only against the Stripe API in test mode. If you attempt to use your physical test card in live mode, the Stripe API returns an error. Unless stated otherwise, use the PIN 1234 when prompted.

When creating payments using a physical test card, use amounts ending in the following values to produce specific responses:

Decimal	Result
00	Payment is approved.
01	Payment is declined with a `call_issuer` code.
02	(Contactless, non-US only) Payment is declined with an `offline_pin_required` code. When using readers featuring a cardholder-facing screen, follow the on-screen prompts to complete the transaction. If a PIN is required, enter the PIN `1234`.
03	(Contactless, non-US only) Payment is declined with an `online_or_offline_pin_required` code. When using readers featuring a cardholder-facing screen, follow the on-screen prompts to complete the transaction. If a PIN is required, enter any 4-digit PIN.
05	Payment is declined with an `generic_decline` code.
55	Payment is declined with an `incorrect_pin` code.
65	Payment is declined with an `withdrawal_count_limit_exceeded` code.
75	Payment is declined with an `pin_try_exceeded` code.

For example, a payment processed using a physical test card for the amount $25.00 succeeds; a payment processed for the amount $10.05 is declined.

Interac test cards Canada only

To test your Interac integration, you must use an Interac physical test card. This can be ordered on the Terminal hardware shop in the Dashboard. The Stripe-branded physical test card can’t be used as an Interac card.

The Interac test card works for both interac_present payments and interac_present refunds. You can use the same test amounts you use for testing card_present payments. Unless stated otherwise, use the PIN 1234 when prompted. To test a declined refund, create a partial refund with an amount ending with the following decimal values: 01, 05, 55, 65, or 75.

The Interac test card doesn’t support tap to pay.

Simulated reader updates

During connection to a simulated Bluetooth reader, you can configure a simulated reader update.

Set the Terminal.shared.simulatorConfiguration.availableReaderUpdate to any of the following configurations. Calling connectBluetoothReader triggers a simulated reader update.

Update Configuration	Result
`SimulateReaderUpdateNone`	No update, no need to communicate anything to your user.
`SimulateReaderUpdateRequired`	A required update is available and takes 1 minute. Your `BluetoothReaderDelegate` receives the `didStartInstallingUpdate` callback.
`SimulateReaderUpdateAvailable`	An optional update is available. Communicate to the user that an update is available and highlight the `requiredAt` date.
`SimulateReaderUpdateLowBattery`	An update attempts and fails due to the reader running low on battery.
`SimulateReaderUpdateRandom`	A random selection of the above scenarios.