How to test and troubleshoot an integration with Myaza Trust
Test the complete integration, including failures and recovery. Choose the supported fixture for the API family you use, then inspect both Myaza’s record and your application’s behaviour.
Charles Archibong, Co-founder
· 3 min read
Key takeaways
- All decision branches reach their intended application path.
- Lost replies and repeated events create no duplicate effect.
- Pending and unavailable remain distinct.
- Fixtures remain explicitly labelled.
- Production-only claims require live evidence.
Test the complete integration, including failures and recovery. Choose the supported fixture for the API family you use, then inspect both Myaza’s record and your application’s behaviour.
Before you begin
A supported Sandbox scenario or labelled sample
Use the correct endpoint family and SDK version
Use a team member with permission for this control. Check the organisation and environment before changing a setting. Review the current price before a paid check or ongoing enrolment. Screenshots show an example workspace or the public integration reference; they do not show a real customer or a completed paid check.
Set up and use the capability
Step 1: Match the product, host and credentials
Choose Sandbox and record the API family you are testing. Identity verification uses the documented /api/kyc host and test key. Risk Intelligence uses its Sandbox /api/v1 host and secret key. Identity Hub has its own /api/identity contract. Do not move request fields between families or infer that every Sandbox request is free. Explicit Risk Intelligence scenarios are non-billable; ordinary requests can use configured pricing.
Integration reference: Sandbox
Step 2: Choose a supported verification scenario
Open the Sandbox & test IDs guide and select an ID that fits the country and document type. For example, the Nigerian BVN fixture ending in 01 passes and 04 produces selfie mismatch. Document-only outcomes need a document ID. Use the published scenario or supported override; real identity numbers are refused by the Sandbox verification contract.
Integration reference: Scenario reference
Step 3: Use the Simulator for supported risk journeys
Open Developers → Simulator in Sandbox. Select a supported scenario and inspect its eligibility. Locked or Setup required scenarios need their displayed prerequisites; do not remove a gate to run them. Travel Rule fixtures need a compatible separately published policy. Running a deterministic scenario proves its controlled handling, not a live provider connection or actual institution exchange.
Integration reference: Set up Sandbox Travel Rule
Step 4: Test the signed receiver independently
Create the Sandbox webhook endpoint and use Testing to simulate a supported event. Verify the signature against raw bytes and persist its logical id. Test a resend, invalid signature, expired signature and a receiver failure. Generated sample identifiers demonstrate shape; they are not reusable API resources for a later retrieve call.
Integration reference: Catalogue-driven fixtures
Step 5: Exercise uncertainty and ordering
Simulate a lost response after a request was accepted, then retry the exact operation with its original references and idempotency key where the contract supports it. Delay or reorder accepted notifications and reconcile current state. Test a pending and unavailable result separately from a decline. Inspect the Myaza record and your durable application state for duplicates or an incorrect access change.
Integration reference: Ordering assertion
Step 6: Keep a concrete Production readiness record
Record the tested scenarios, intended decision, observed decision, backend action and recovery evidence. Check supported SDK versions, permission recovery and representative devices. Set up the separate Production workflow, keys and receiver only after business and capability requirements are satisfied. Remove Sandbox-only scenario fields. A green local test or example score is not evidence of live customer behaviour.
Integration reference: Checklist for going live
Get more from the capability
Keep fixtures in the same form as the public contracts so your test suite catches field and version changes.
Test late final decisions for workflows that wait on screening, key people or presence.
Give operational failures their own customer-safe message and internal recovery path rather than asking the applicant to fix a service outage.
Test before relying on it
Run the supported Sandbox or simulator scenarios for this product. Where a tool is Production only, check access and scope first, then use only a permitted, deliberately reviewed Production test. A documentation screenshot or a successful page load is not an end-to-end integration test.
All decision branches reach their intended application path.
Lost replies and repeated events create no duplicate effect.
Pending and unavailable remain distinct.
Fixtures remain explicitly labelled.
Production-only claims require live evidence.
Troubleshooting
My real ID was rejected in Sandbox
Use a published test ID. Sandbox verification does not validate real identity numbers.
A Simulator scenario is locked
Complete its displayed policy or controlled-fixture prerequisites.
A sample resource cannot be retrieved
Catalogue samples illustrate shapes; their IDs are not live stored resources.
Open the setup and integration references
Read the integration reference
Back to Solutions. Choose the capability you want to activate, then follow its own guide.
Sources
Charles Archibong
Co-founder
Charles Archibong co-founded Myaza Trust. He writes about identity verification, financial technology, and the practical work of building trusted digital services.
