Testing Guide
Overview
This guide provides comprehensive testing scenarios for KOIN payment integration. All examples use the sandbox environment where no real money is processed.
Sandbox Environment
Base URL:
https://api.firstoken-staging.co/v1/payments/Environment: Complete simulation of production KOIN processing
Test Cards: Any valid card format works in sandbox
Real-time Testing: All flows work exactly like production
Test Card Numbers
For KOIN testing, you can use any valid card number format. The payment processing is simulated based on other request parameters.
Test Card Numbers
For KOIN testing, you can use any valid card number format. The system will simulate the payment flow:
Visa
4111 1111 1111 1111
Any 3-digit
Standard test
Mastercard
5555 5555 5555 4444
Any 3-digit
Standard test
American Express
3782 8224 6310 005
Any 4-digit
Requires 4-digit CVV
Important Notes:
Use any expiration date in the future (MM/YYYY format)
Cardholder name can be any valid name format
All cards work in sandbox for testing different scenarios
Amount-Based Testing
Control transaction outcomes by using specific amounts in your test requests. KOIN uses transaction amounts to simulate different scenarios:
1 - 5000
Authorized
Collected
Success
5001 - 10000
Authorized
Failed
ChannelRejected
10001 - 15000
Authorized
Failed
InsufficientFunds
15001 - 20000
Authorized
Failed
InvalidCard
20001 - 25000
Authorized
Failed
InvalidData
25001 - 30000
Authorized
Failed
Referred
30001 - 35000
Authorized
Failed
ExpiredCard
35001 - 40000
Authorized
Failed
StolenCard
40001 - 45000
Authorized
Failed
ConnectionRefused
50001 - 55000
Processorerror
Authorized
Undefined
60000 - 65000
Opened
Authorized
Success
65001 - 70000
Unknown
Authorized
Success
+ 150000
Authorized
Collected
Success
Example: To test a successful payment, use amount 1000 . To test antifraud review, use amount 42000 .
Antifraud Testing with Email Patterns
Test different antifraud scenarios using specific email patterns in cardholder_info.email and bill_to.email:
{username}+autoaccept@{emailprovider}
Automatically accepted
Transaction will be accepted
{username}+autoreject@{emailprovider}
Automatically rejected
Transaction will be rejected
{username}+prereject@{emailprovider}
Rejected at authorization
Transaction will be rejected at the authorization stage
{username}+preaccept_autoaccept@{emailprovider}
Accepted at all stages
Transaction will be accepted at all stages
{username}+preaccept_autoreject@{emailprovider}
Mixed result
Accepted at authorization, rejected at evaluation
Example Email Patterns
json
Complete Test Scenarios
1. Successful Payment Flow
2. Authorization + Capture Flow
Step 1: Authorization
Step 2: Capture (use transaction_id from step 1)
3. Authorization + Void Flow
Step 1: Authorization (same as above)
Step 2: Void (use transaction_id from step 1)
4. Payment + Refund Flow
Step 1: Payment (use payment example above)
Step 2: Void (use transaction_id from step 1)
Error Testing Scenarios
1. Missing Required Fields
2. Invalid CPF Format
Best Practices for Testing
Use Unique IDs: Always generate unique transaction IDs
Test All Flows: Test complete workflows, not just individual endpoints
Error Handling: Test both success and failure scenarios
Documentation: Document test cases and expected results
Environment Separation: Keep test data clearly separated from production
Last updated
Was this helpful?