YCMT EU Partner Developer
Sandbox and Go-Live Guide
Partner developer integration pack | Version 1.0 | YCMT EU
| Partner-safe scope
This guide explains how a partner development team should test the YCMT EU integration in sandbox and prepare for production activation. It covers test environments, scenarios, evidence, readiness checks, and go-live steps. It does not describe YCMT internal implementation, internal risk rules, or internal operating systems. |
|---|
| Field | Value |
|---|
| Document | 60_YCMT_EU_PartnerDev_Sandbox_And_GoLive_Guide_v1_0.docx |
| Audience | Partner developers, partner QA, partner technical leads, partner release managers |
| Perimeter | YCMT EU only |
| Status | Draft for partner onboarding use |
| Confidentiality | Partner-facing under onboarding/NDA controls |
| Related pack files | Getting Started; API Guide; Flows Guide; Errors, Statuses and Retry Guide; Security and Signing Guide; OpenAPI and Postman Pack |
Contents
- 1. Purpose of sandbox testing
- 2. Environments and credentials
- 3. Sandbox data rules
- 4. Minimum integration test plan
- 5. Positive test scenarios
- 6. Negative and recovery scenarios
- 7. Evidence required for go-live review
- 8. Production readiness checklist
- 9. Production activation process
- 10. Post-go-live monitoring
- 11. Change management and version notices
- 12. Appendix: partner test log template
1. Purpose of sandbox testing
Sandbox testing proves that the partner application can integrate safely with the YCMT EU APIs before production credentials are issued or activated. The goal is not only to show that happy-path calls work. The partner must also demonstrate correct handling of failures, retries, status polling, webview returns, token expiry, and customer-safe remediation paths.
| Testing objective | Expected outcome |
|---|
| API connectivity | Partner can call the documented sandbox endpoints using issued sandbox credentials. |
| Customer journey | Partner can complete the end-to-end customer flow from onboarding to transfer status. |
| Resilience | Partner handles retryable failures, duplicate requests, expired sessions, and validation errors correctly. |
| Security | Partner protects tokens, keys, webhook materials, and customer data. |
| Operational readiness | Partner support and release teams know how to trace, escalate, and evidence issues. |
| Go-live principle
Production access is granted only after YCMT confirms that the partner has completed the required sandbox scenarios, implemented the required controls, and provided the requested evidence. |
|---|
2. Environments and credentials
YCMT separates sandbox and production environments. Credentials, webhooks, signing keys, test customers, and logs must be kept separate.
| Environment | Purpose | Data rule |
|---|
| Sandbox | Development, QA, integration testing, negative scenarios, go-live evidence. | Use fictional or YCMT-approved test data only. No real customer data. |
| Production | Live customer traffic after go-live approval. | Use production credentials only after activation. Production data is live customer data. |
| Credential or asset | Sandbox | Production |
|---|
| API base URL | Provided during onboarding. | Provided after go-live approval. |
| Partner API credential | Sandbox-only credential. | Production credential activated after readiness approval. |
| Webhook endpoint | Sandbox endpoint recommended. | Production endpoint must be reachable and monitored. |
| Quote-signing key | Sandbox key or test key. | Production key must be protected and registered before production use. |
| Test users | YCMT-approved fictional test users. | Real customers only. |
| Environment separation rule
Do not use production credentials, production customer data, production signing keys, or production webhook secrets in sandbox. Do not send sandbox events to production systems unless YCMT has approved a controlled test. |
|---|
3. Sandbox data rules
- Use fictional personal data or YCMT-provided test profiles only.
- Do not upload real identity documents, real customer addresses, real phone numbers, or live financial details unless YCMT has explicitly authorised a controlled test.
- Use test beneficiaries and test payout details supplied or approved by YCMT.
- Do not treat sandbox transaction results as real payments or customer obligations.
- Remove test data from partner logs and screenshots before sharing externally unless YCMT requests them for go-live evidence.
4. Minimum integration test plan
The following test plan is the minimum expected before go-live review. YCMT may add corridor-specific, partner-specific, or risk-specific tests during onboarding.
| Test group | Required before go-live | Evidence expected |
|---|
| Connectivity and credentials | Yes | Successful health/connectivity call or agreed equivalent. |
| Authentication and registration | Yes | Screenshots/log extracts showing registration, login, refresh, logout. |
| Customer profile and KYC | Yes | Profile submission and KYC session completion or sandbox simulated result. |
| Beneficiaries | Yes | Create, list, retrieve, and archive where supported. |
| Quote and disclosure | Yes | Quote retrieval/creation path, disclosure presentation, quote acceptance. |
| Transfer lifecycle | Yes | Submit transfer, confirm if required, funding webview, status polling. |
| Errors and recovery | Yes | At least the negative scenarios in section 6. |
| Security and signing | If applicable | Quote-signing, device confirmation, webhook verification, key handling evidence. |
| Webhook receipt | If enabled for partner | Successful receipt, verification, idempotent processing, retry handling. |
5. Positive test scenarios
Positive scenarios prove that the partner can complete expected customer journeys without manual intervention.
| ID | Scenario | Expected result |
|---|
| P-01 | New customer registers and logs in. | Customer obtains access token and can continue to profile/KYC. |
| P-02 | Returning customer logs in. | Existing customer session starts successfully. |
| P-03 | Customer submits profile details. | Profile is accepted or returns customer-safe validation feedback. |
| P-04 | Customer starts KYC session. | Partner app opens the YCMT-provided KYC webview or follows the documented redirect/return process. |
| P-05 | Customer creates beneficiary. | Beneficiary is created and available in list/detail endpoints. |
| P-06 | Customer retrieves quote and disclosure. | Partner app shows amount, fees, FX, payout details, and disclosure before acceptance. |
| P-07 | Customer accepts quote. | Quote acceptance succeeds while the quote is valid. |
| P-08 | Customer submits transfer. | Transfer is created/submitted and status polling becomes available. |
| P-09 | Customer completes confirmation/funding where required. | Funding webview or confirmation flow completes and transfer status progresses. |
| P-10 | Partner app polls transfer status. | Partner app displays customer-safe status and next action. |
6. Negative and recovery scenarios
Negative scenarios prove that the partner app does not break, mislead customers, duplicate transactions, or expose sensitive information when the API returns expected errors.
| ID | Scenario | Expected partner behaviour |
|---|
| N-01 | Invalid credentials or failed login. | Show generic login failure. Do not reveal whether identifier exists. |
| N-02 | Expired access token. | Refresh where supported or ask the customer to log in again. |
| N-03 | Quote expired before acceptance. | Ask customer to refresh/recreate quote. Do not submit old quote. |
| N-04 | Unsupported destination or payout method. | Show customer-safe message and prevent further submission. |
| N-05 | KYC not complete. | Direct customer to complete required onboarding/KYC step. |
| N-06 | Customer status prevents action. | Show approved remediation or support message. Do not reveal internal reason. |
| N-07 | Duplicate submission with same idempotency key. | Treat returned result as the authoritative result of the original request. |
| N-08 | Rate limit or temporary service issue. | Retry only according to documented backoff; do not create retry storms. |
| N-09 | Webhook duplicate delivery. | Process idempotently and avoid duplicate partner-side actions. |
| N-10 | Webhook signature or freshness failure. | Reject event and escalate if repeated. |
| Customer-safe error handling
Partner apps must not expose internal explanations, internal identifiers, risk flags, sanctions details, screening reasons, or manual-review details. Use the documented customer-safe remediation text and escalation process. |
|---|
7. Evidence required for go-live review
The partner must provide concise evidence that the integration has been tested. Evidence does not need to include secrets, tokens, real personal data, or full request payloads containing sensitive data.
| Evidence item | Required content |
|---|
| Completed test log | Scenario ID, date, environment, result, correlation ID where available, tester name/team. |
| Screenshots or screen recording | Customer-facing flow evidence with test data only. Hide tokens and secrets. |
| API logs summary | Endpoint, timestamp, status code, correlation ID, result. No tokens or secrets. |
| Error-handling evidence | Examples of customer-safe handling for expired token, expired quote, validation error, and retryable failure. |
| Security evidence | Confirmation of secure credential storage, token handling, and no sensitive logging. |
| Webhook evidence | If applicable: received event, verification result, idempotent processing result. |
| Release plan | Target launch date, responsible technical contact, monitoring approach, rollback/contact plan. |
8. Production readiness checklist
| Area | Readiness requirement |
|---|
| API integration | All required endpoints used according to the API Guide and Flows Guide. |
| Error handling | All required negative scenarios handled with customer-safe messaging. |
| Security | Tokens, credentials, keys, and webhook secrets protected; sensitive data excluded from logs. |
| Idempotency and retry | Applicable POST actions use idempotency keys; retry logic uses documented backoff. |
| Webviews | KYC and funding webview redirects/returns handled correctly. |
| Webhooks | Endpoint reachable; verification and duplicate handling implemented if webhooks are enabled. |
| Support readiness | Partner support team knows escalation route and required correlation information. |
| Monitoring | Partner monitors API failures, webhook failures, customer drop-offs, and release errors. |
| Production configuration | Production base URL, credentials, signing keys, and webhook endpoint configured separately from sandbox. |
| Change freeze | No untested integration changes between go-live approval and launch without notifying YCMT. |
| Production activation gate
Do not switch live customers to production until YCMT confirms production activation. Sandbox success alone does not authorise production launch. |
|---|
9. Production activation process
- Partner completes the required sandbox test plan.
- Partner submits test evidence and production readiness checklist to YCMT.
- YCMT reviews evidence and confirms any remediation items.
- Partner remediates open items and re-tests where required.
- YCMT issues or activates production credentials and production endpoint details.
- Partner configures production environment without copying sandbox secrets or test data.
- Partner and YCMT agree the launch window and support contacts.
- Partner performs a controlled production smoke test if YCMT authorises it.
- Partner launches customer traffic according to the agreed plan.
10. Post-go-live monitoring
For the first production release, the partner should monitor integration performance closely and keep a named technical contact available during the agreed launch window.
| Metric or signal | Partner action |
|---|
| Authentication failures above expected level | Check release/configuration; escalate with timestamps and correlation IDs. |
| High quote or transfer failure rate | Check request construction and customer messaging; escalate if not explained. |
| Webhook delivery or verification failures | Check endpoint availability, verification code, clocks, and firewall rules. |
| Unexpected customer drop-off in KYC/funding webview | Check redirect/return handling and app state recovery. |
| Rate-limit responses | Reduce request volume, fix retry logic, and avoid retry storms. |
| Customer complaints about transfer status | Use transfer status endpoint and support escalation route. Do not speculate on internal review reasons. |
11. Change management and version notices
- Track the API changelog supplied in the OpenAPI and Postman Pack.
- Test against sandbox before adopting any new endpoint or optional field.
- Treat removed fields, changed required fields, changed enum values, changed authentication behaviour, or changed signing requirements as breaking changes unless YCMT states otherwise.
- Keep backward-compatible parsing where possible: ignore unknown response fields unless your application specifically needs them.
- Notify YCMT before major partner-app releases that affect registration, login, KYC, quote acceptance, transfer submission, funding, signing, or webhook handling.
12. Appendix: partner test log template
| Field | Example |
|---|
| Scenario ID | P-07 |
| Scenario name | Customer accepts quote |
| Environment | Sandbox |
| Date/time | YYYY-MM-DD HH:MM UTC |
| Tester | Partner QA / engineer name |
| Result | Pass / Fail / Blocked |
| API status code | 200 / 400 / 401 / etc. |
| Correlation ID | Correlation ID from response/header/log, if available |
| Evidence reference | Screenshot name, log extract reference, test case link |
| Notes | What happened; no secrets, tokens, or real personal data |
| Final developer reminder
A successful integration is not just a successful happy path. YCMT expects partner apps to handle failed, expired, delayed, duplicated, and customer-action-required states safely and clearly. |
|---|