Testing

Topics covered on this page

Testing Guide

Testing Guide

Overview

This comprehensive testing guide helps you validate your Omise integration before going live. Use the following test card numbers and scenarios to simulate various payment outcomes and ensure your application handles all edge cases correctly.

Important: All test card numbers work with any expiration date and security code in test mode.

How to Enable Testing

Test Mode: Available in all Omise accounts by default
API Version: Compatible with all API versions
Supported Testing: All payment methods and currencies supported in live mode

Test Card Numbers

Creating Successful Charges

Use these card numbers to generate successful charges:

Brand	Number
Visa	4242 4242 4242 4242
Visa	4111 1111 1111 1111
Mastercard	5555 5555 5555 4444
Mastercard	5454 5454 5454 5454
JCB	3530 1113 3330 0000
JCB	3566 1111 1111 1113
Amex	3782 8224 6310 005
Discover	6447 0324 0000 0000 001
Diners	3602 1042 0000 04
UnionPay	6250 9470 0000 0006

Creating Failed Charges

These card numbers can create a charge with a specific failure_code. See the Charges API for more information about these failure codes:

Failure Code	Brand	Number
`insufficient_fund`	Visa	4111 1111 1114 0011
`insufficient_fund`	Mastercard	5555 5511 1111 0011
`insufficient_fund`	JCB	3530 1111 1119 0011
`insufficient_fund`	UnionPay	6250 9470 0000 0014
`stolen_or_lost_card`	Visa	4111 1111 1113 0012
`stolen_or_lost_card`	Mastercard	5555 5511 1110 0012
`stolen_or_lost_card`	JCB	3530 1111 1118 0012
`stolen_or_lost_card`	UnionPay	6250 9470 0000 0022
`failed_processing`	Visa	4111 1111 1112 0013
`failed_processing`	Mastercard	5555 5511 1119 0013
`failed_processing`	JCB	3530 1111 1117 0013
`failed_processing`	Amex	3771 3816 0000 009
`failed_processing`	Discover	6447 0324 0000 1111 005
`failed_processing`	Diners	3602 1042 1111 08
`failed_processing`	UnionPay	6250 9470 0000 0030
`payment_rejected`	Visa	4111 1111 1111 0014
`payment_rejected`	Mastercard	5555 5511 1118 0014
`payment_rejected`	JCB	3530 1111 1116 0014
`payment_rejected`	UnionPay	6250 9470 0000 0048
`failed_fraud_check`	Visa	4111 1111 1119 0016
`failed_fraud_check`	Mastercard	5555 5511 1116 0016
`failed_fraud_check`	JCB	3530 1111 1114 0016
`failed_fraud_check`	UnionPay	6250 9470 0000 0055
`invalid_account_number`	Visa	4111 1111 1118 0017
`invalid_account_number`	Mastercard	5555 5511 1115 0017
`invalid_account_number`	JCB	3530 1111 1113 0017
`invalid_account_number`	UnionPay	6250 9470 0000 0063

Creating Failed 3DS Charges

These card numbers can result in a charge with a payment_rejected failure code. See the Charges API for more information about the payment_reject failure codes.

The 3DS failure may be due to enrollment or validation issues. An enrollment failure occurs when there is an issue with creating the charge, for instance, by neglecting to provide a return URI. A validation failure occurs when there is an issue validating the charge with 3DS, for example, by entering the wrong one-time password.

Note: These card numbers can only be used with a 3D Secure (3DS)- enabled account. Contact support@omise.co to enable 3D Secure (3DS) for your test account.

3DS Failure Type	Brand	Number
Enrollment	Visa	4111 1111 1115 0002
Enrollment	Mastercard	5555 5511 1112 0002
Enrollment	JCB	3530 1111 1110 0002
Enrollment	UnionPay	6250 9470 0000 0071
Validation	Visa	4111 1111 1114 0003
Validation	Mastercard	5555 5511 1111 0003
Validation	JCB	3530 1111 1119 0003
Validation	Amex	3771 3816 1111 003
Validation	Discover	6447 0324 0000 2222 009
Validation	Diners	3602 1042 2222 02
Validation	UnionPay	6250 9470 0000 0089

Testing Procedures

Standard Card Testing

Creating a Test Charge

To create a test charge, use your test API keys with the preceding test card numbers. Include the required parameters, such as the amount (in the smallest currency unit), currency, and card token.

Required Parameters

All test charges require the amount, currency, and card token parameters.

Optional Parameters

You can include additional parameters, such as a description and metadata, for tracking and reference purposes.

Basic Integration Testing

Integration Setup

Ensure you're using test API keys
Configure your application to use the test environment
Set up proper error handling for different response codes

Basic Charge Testing

Create charges using successful test cards
Verify charge status updates correctly
Test webhook delivery for charge events
Confirm proper handling of successful responses

Failure Scenario Testing

Test each failure card number
Verify your application displays appropriate error messages
Ensure failed charges don't complete the transaction flow
Test retry mechanisms if implemented

Webhook Testing

Set up webhook handlers to receive real-time payment updates. Configure webhook endpoints in your test dashboard and implement proper signature verification for security.

Status Checking

You can manually check the current status of a payment by retrieving the charge information from the API. This is useful for polling payment status as an alternative to webhooks.

3D Secure Testing

Understanding 3DS Test Requirements

Important: 3DS testing requires a 3DS-enabled account. Contact support@omise.co to enable 3DS for your test account before proceeding with 3DS testing scenarios.

Testing Successful 3DS Flows

For successful 3DS authentication testing, you can use any of the standard successful charge cards from the successful charges table above in combination with 3DS-enabled transactions:

Create a 3DS Charge

Use any successful test card number (e.g., 4242 4242 4242 4242)
Include the return_uri parameter in your charge request
Ensure your account has 3DS enabled
The initial charge status will be pending

Complete Authentication

Customer will be redirected to the 3DS authentication page
In test mode, you'll see a mock authentication interface
Enter any valid OTP or use the mock interface to complete authentication
Customer will be redirected to your return_uri

Verify Final Status

Check charge status after redirect (should be successful)
Verify webhook notifications are received
Confirm your application completes the purchase flow

Testing Failed 3DS Flows

Use the specific 3DS failure test cards from the preceding Creating Failed 3DS Charges table to test different failure scenarios:

Enrollment Failures (Issues with charge creation)

Use enrollment failure test cards
These simulate problems like missing the return_uri parameter
The charge will fail before reaching the authentication step

Validation Failures (Issues during authentication)

Use validation failure test cards
These simulate authentication problems, such as a wrong OTP
Charge reaches authentication but fails during validation

Testing Process

Create a charge using 3DS failure test cards
Follow the authentication flow
Verify appropriate failure handling
Check that your application shows proper error messages

Alternative Payment Methods Testing

Internet Banking Testing

For payment methods that require external authorization (like Internet Banking), use the dashboard Actions menu to simulate:

Successful bank authorization
Failed bank authorization
Timeout scenarios

Testing Process:

Create Charge

Generate a charge using the test API for the specific payment method
Charge status will be pending

Simulate Payment Authorization

Navigate to the specific charge in your Omise dashboard
Click Actions
Select either Mark as Successful or Mark as Failed
This simulates the customer completing or canceling the payment

Expected Results

Successful: Charge status changes to successful, webhook triggered
Failed: Charge status changes to failed, appropriate error webhook sent

Test Scenarios Checklist

Basic Integration Testing

[ ] Successful charges with each supported card brand
[ ] Failed charges with various decline reasons
[ ] Webhook delivery and processing
[ ] Proper error message display
[ ] Transaction logging and reconciliation

3D Secure Testing

[ ] Successful 3DS authentication flow
[ ] Failed 3DS authentication
[ ] 3DS unavailable scenarios
[ ] Proper redirect handling
[ ] Status verification after authentication

Edge Cases

[ ] Network timeout handling
[ ] Duplicate charge prevention
[ ] Currency validation
[ ] Amount limit testing
[ ] Invalid card data handling

Alternative Payment Methods

[ ] QR payment simulation
[ ] Internet banking simulation
[ ] Installment plan testing (if applicable)
[ ] Wallet payment testing (if applicable)

Dashboard Testing Features

Manual Charge Status Updates

For payment methods that require external authorization (such as Internet Banking), use these dashboard features:

Access Charge Details

Go to Charges on your dashboard
Find the pending charge you want to test
Click the charge ID to view details

Use Actions

Click the Actions dropdown in the charge details
Select Mark as Successful to simulate successful payment
Select Mark as Failed to simulate payment failure

Verify Results

Check that charge status updates correctly
Confirm webhook notifications are sent
Test your application's response to status changes

Dashboard Button Reference

In test mode, yellow buttons indicate functionality specific to this mode. These buttons allow you to simulate processes that can't be directly duplicated in test mode (e.g., marking a transfer as paid).

Best Practices

For All Merchants

Test all card brands you plan to accept
Verify webhook endpoint security and processing
Test error handling for all failure scenarios
Validate proper customer experience for both success and failure

For Enterprise Merchants

Conduct comprehensive UAT with your SC team
Test high-volume scenarios
Validate reporting and reconciliation processes
Test failover and redundancy mechanisms

For Mid-Tier and Small Merchants

Focus on common failure scenarios first
Test the complete customer journey
Verify proper error messages are user-friendly
Ensure the mobile experience is tested thoroughly

Going Live Checklist

Before switching to production:

[ ] All test scenarios pass successfully
[ ] Webhook endpoints are secure and processing correctly
[ ] Error handling provides clear user guidance
[ ] Live API keys are properly configured
[ ] Monitoring and alerting are in place
[ ] Customer support processes are established

Frequently Asked Questions

General Testing Questions

What is the difference between test mode and live mode?

Test mode allows you to simulate transactions without processing real payments. All API calls function similarly, but no actual money is transferred. Live mode processes real transactions with real payment methods.

How do I switch between test and live modes?

Use your test API keys for testing and live API keys for production. The mode is determined by which set of API keys you use in your requests.

Can I use real card numbers in test mode?

No, you should only use the designated test card numbers provided in this guide. Real card numbers may not work correctly in test mode and could cause unexpected behavior.

What happens if I accidentally use test API keys in a production environment?

Test API keys will not process real transactions. Customers will not be charged, and you'll receive test data instead of real payment confirmations.

How long should I test before going live?

Test until you've covered all payment scenarios your customers might encounter, including success cases, all failure types, and edge cases like network timeouts.

Test Card Questions

Do test card numbers work with any expiration date?

Yes, test card numbers work with any future expiration date and any security code in test mode.

Why do some test cards have specific failure codes?

Different test cards simulate different real-world failure scenarios, helping you test how your application handles various error conditions that customers might encounter.

Can I create custom test cards?

No, you must use the predefined test card numbers. These are specifically designed to work with Omise's test environment.

How often are test card numbers updated?

Test card numbers are stable and rarely change. Any updates will be announced in advance through our developer documentation.

What should I do if a test card isn't working as expected?

First, verify that you're using the correct test API keys and the exact card number as specified in the documentation. If issues persist, contact support with the specific test scenario details.

3D Secure Testing Questions

How do I enable 3DS testing for my account?

Contact support@omise.co to enable 3DS for your test account. This is required before you can test 3DS flows.

What's the difference between enrollment and validation failures?

Enrollment failures: Issues with setting up the 3DS process (e.g., missing return_uri)
Validation failures: Issues during authentication (e.g., wrong OTP or authentication timeout)

Can I test successful 3DS flows with regular test cards?

Yes, once 3DS is enabled for your account, you can use regular successful test cards for 3DS authentication. The specific 3DS test cards are only for testing failure scenarios.

How do I simulate the 3DS authentication interface?

In test mode, you'll see a mock authentication page. You can choose to complete or fail the authentication to test different outcomes.

Why is my 3DS test returning to the wrong URL?

Ensure your return_uri parameter is correctly formatted and accessible. The URL must be reachable from the internet for proper testing.

Alternative Payment Method Questions

How do I test payment methods, such as Internet Banking?

Use the dashboard's Actions button to mark pending charges as successful or failed manually. This simulates the external payment completion process.

Why can't I complete alternative payment method testing through the API?

Alternative payment methods often require external processes (like bank authorization) that can't be automated. The dashboard simulation provides a way to test these scenarios.

Do alternative payment methods support the same test scenarios as cards?

Alternative payment methods primarily support success/failure testing through dashboard simulation. Card-specific scenarios (like fraud checks) don't apply to these payment methods.

Where do I find the Actions button in the dashboard?

Navigate to Charges, click a specific charge, and look for the yellow Actions button in the charge details page.

Implementation Questions

How do I know when a payment is complete in test mode?

Set up webhook handlers to receive real-time notifications, or poll the charge status using the API. Both methods function identically in test and live modes.

Should I implement different logic for test mode?

Your application logic should be identical for test and live modes. Only the API keys should differ between environments.

How do I test webhook delivery?

Configure webhook endpoints in your test dashboard and use the webhook testing tools. You can also use services like ngrok to expose local development servers for webhook testing.

Can I test refunds and voids?

Yes, you can test refunds on successful test charges and voids on pending test charges using the same API calls you'll use in production.

How do I test timeout scenarios?

Implement artificial delays in your test environment or temporarily block network requests to simulate poor connectivity and timeout conditions.

Webhook Questions

My webhooks aren't being received. What should I check?

Verify your webhook URL is publicly accessible
Ensure your endpoint returns an HTTP 200 status
Check that you're not blocking Omise's IP addresses
Use the dashboard webhook tester to verify your endpoint

How do I verify webhook signatures in test mode?

Use the same signature verification process as in live mode. Test mode webhooks are signed with your test webhook secret key.

Should I process webhooks differently in test mode?

No, process test webhooks exactly as you would in live mode. This ensures your webhook handling logic is tested correctly.

Can I test webhook retries?

Yes, return non-200 status codes from your webhook endpoint to trigger Omise's retry mechanism and test your retry handling.

Troubleshooting

Common Issues and Solutions

Test charges are failing unexpectedly

Symptoms: Charges created with test cards are returning failure status when they should succeed.