1. Assess requirements
Describe the business activity, registered country, customer journey, website or application, and order records. Identify payment methods and specialized flows as requirements to assess. Establish the proposed division of responsibilities and the partner requirements that may affect scope. The outcome of this stage is an agreed starting point, not permission to process live payments.
2. Agree access arrangements
Once the appropriate scope is established, clarify which environment and technical materials can be supplied, who may access them, and how access will be managed. Credentials must be handled through the agreed secure arrangements. This website does not issue keys or provide a public sandbox. Do not put credentials, payment details, or sensitive files into an initial enquiry.
3. Implement the confirmed design
Use only the documentation and interfaces confirmed for the integration. Map the merchant’s business references to the supported transaction records and define how the application responds to outcomes. Keep operational responsibilities visible in the design. Any conceptual flow shown on this site explains the architecture only; it cannot be used as a production endpoint, payload specification, or SDK example.
4. Test the full journey
Agree scenarios for success, refusal, interruption, repeat actions, delayed outcomes, and relevant refund or dispute workflows. Check order matching and the information visible to the operations team. Record the test result and any unresolved issue using the agreed process. Where a feature is outside the confirmed scope, do not treat an illustrative concept as evidence that it works.
5. Validate, then consider activation
Validation should establish that the agreed technical and operational requirements have been met. Confirm who supports the merchant, how issues are raised, and which processing arrangements apply. No activation date or live-processing availability is guaranteed by this planning guide.