- Get Started
- Guides
- Integrations
- References
- API Reference
- Basic Payment
- Forex
- Authentication
- Card Account
- Apple Pay
- Virtual Account
- Bank Account
- Token Account
- Customer
- Billing Address
- Merchant Billing Address
- Shipping Address
- Merchant Shipping Address
- Corporate
- Sender
- Recipient
- Merchant
- Marketplace & Cart
- Airline
- Lodging
- Passenger
- Tokenization
- Recurring Migration
- 3D Secure
- Custom Parameters
- Async Payments
- Webhook notifications
- Job
- Risk
- Point of Sale
- Response Parameters
- Card On File
- Chargeback
- Result Codes
- Payment Methods
- Transaction Flows
- Regression Testing
- Data Retention Policy
- Release Notes
- API Reference
- Support
Regression Testing
Why?
Our platform is getting enhanced on a daily basis and code drops are happening continuously. We use the Continuous Integration and Continuous Delivery/Continuous Deployment methodology in which incremental code changes are made and deployed frequently to the platform.
We strive for perfection in agility and quality, and are running multiple thousands of unit tests, regression tests, black box tests on a daily basis. Fully automated within our Continuous Integration/Continuous Deployments pipelines, code drops will only be promoted to the production environment after all pipelines being green.
Apart from our automated tests, merchants are encouraged to have their own set of regression tests to validate their integration will be working after each change.
When?
We are offering a 24/7, fully functional UAT environment and allow our merchants to build automated regression test to ensure a fully functional end-to-end consumer workflow.
With that promise, the merchant will be able to identify defects at any time, in a fully automated way and can react prior to any production code drop.
How?
It's strongly recommended to have automated regression tests, as we are continuously performing code changes and releasing them to UAT and weekly to production. Manual testing is not recommended.
Merchants should test all workflows they have implemented with us for all brands used in production. For example: if a merchant uses Pre-Authorizations, their tests should also include Captures.
Start by creating channels in our UAT environment to send the transactions, trying to simulate as much as possible the production environment.
Don't use production MIDs or production configuration data in UAT. Check the integration sheet for each connector you use to get the corresponding test data.
Never use real cards for testing. Instead, use the test cards listed here.
Server-to-Server Integration
This integration doesn’t involve a web browser. They can be tested by sending requests to our API and verifying the response.
The API documentation can be found here.
Check the interactive tutorials here.
For back-office transactions (Captures, Reversals, Refunds), check this documentation.
COPYandPAY Integration
This integration needs a browser to be tested and we recommend that you check your integration using a payment page exactly as your production payment page. This will ensure that any change in the payment widget will be checked using your current production integration.
We recommend running the tests using different browsers, as there could be differences in the execution of JavaScript on each browser. Look for a Cross-Browser Testing Tool that fits your need. If you just want to test with Chrome, you can use the headless version of Chrome with different test frameworks.
Check the interactive tutorials here.
Webhooks
You can always configure a Webhook in our UAT environment to receive the notifications about transactions, like you would do in production. This is strongly recommended.
For more information on how to use the Webhooks, please visit this page.
What if we find a problem?
If you have a test starting to fail after it was successful for some time, we should be informed immediately.
Please inform in the subject that this is a UAT Integration Problem. We check for all tickets referring to UAT, especially before each release, and give them high priority to avoid releasing changes that might break customer integrations.