Phase 6 — Compliance Review & Activation

📘
Part of Merchant Acquiring Reseller — Phase 6 of 6 · Actors: Reseller / Merchant / Compliance
The merchant accepts the Terms & Conditions digitally, the reseller submits the case for review, EFT Corporation compliance audits the website and adjudicates any screening hits, then unbars the wallet. You (the reseller) confirm go-live and retain the key identifiers.

Step 16 — Merchant accepts the Terms & Conditions (digital)

Before the case is submitted for review, the merchant must accept the EFT Corporation Terms & Conditions digitally. Initiate the acceptance for the organisation, then present the returned acceptanceUrl to the merchant to read and accept.

Actors: Reseller (initiates) · Merchant (reads and accepts)

⚠️
First time only
This step is required only on first onboarding, before the initial submit-for-review (Step 17). It does not need to be repeated for later re-reviews.

POST /eclipse-conductor/rest/v1/tenants/{tenantId}/integrations/JA-terms-and-conditions-initiate

Request body

{
  "organisationId": "{organisationId}",
  "returnUrl": "https://yourdomain.com/completed"
}

Field	Notes
`organisationId`	The organisation being onboarded (from Phase 1, Step 01)
`returnUrl`	Optional page redirect on completion of the terms and conditions

Response

Field	Notes
`acceptanceUrl`	The URL to present to the merchant. The merchant must open, read, and accept the Terms & Conditions here.

Retrieve the signed Terms & Conditions (Optional Step)

Once accepted, the signed T&Cs are stored as a terms.acceptance attachment on the organisation. Retrieve the signed PDF at any time:

GET /eclipse-conductor/rest/v1/tenants/{tenantId}/organisations/{organisationId}/attachments?attachmentType=terms.acceptance

Field	Notes
`base64EncodedAttachment`	The signed Terms & Conditions, returned as a Base64-encoded PDF

📘
Sandbox host
On the sandbox, the base URL is https://eclipse-java-sandbox.ukheshe.rocks. This is a dedicated Terms & Conditions API — it is not the organisation attachments upload used in Phase 3, Step 09.

Step 17 — Submit for compliance review

Explicitly request an EFT Corporation compliance review. This is the reseller's signal that the case is ready to be adjudicated. Call it the first time once the merchant has accepted the Terms & Conditions (Step 16) — which follows wallet creation in Phase 4, Step 13 — and again every time you make changes to the merchant record that require EFT Corporation to re-review.

Actor: Reseller

POST /eclipse-conductor/rest/v1/tenants/{tenantId}/organisations/{organisationId}/attachments

📎 API reference: Add an attachment to the organisation

Field	Value	Notes
`attachmentType`	`SUBMIT_FOR_REVIEW`	Mandatory — flags the organisation for compliance review
`fileName`	`Merchant Review`	Mandatory — use this exact value
`info`	`true`	Mandatory — always set to `true`
`mediaType`	`text/plain`	Required in practice — the backend rejects a null `media_type` with `400 SQL001`, even though the API spec marks it optional

📘
Call this on first submission and on every re-review
Submit once after the merchant accepts the T&Cs to open the initial compliance review. Whenever the merchant's details or documents change afterwards and you need EFT Corporation to review them again, call this endpoint again with the same values to re-queue the case.

Step 18 — Website audit and screening review

EFT Corporation compliance reviews the merchant's website and adjudicates any screening hits from Phase 5, Step 15.

Actor: Compliance

Manual review by the EFT Corporation compliance team, triggered by the submit-for-review call in Step 17. Ensure the merchant's website URL is set on the organisation via the businessWebsite field (Phase 1, Step 01 or Phase 4, Step 10). Where screening hits were found, compliance adjudicates each one — you may be contacted for additional documentation (Enhanced Due Diligence).

Possible outcomes

Outcome	What it means
Cleared	Proceed to activation in Step 19
EDD required	Compliance requests additional documents; upload via Phase 3, Step 08 or Phase 2, Step 05 as applicable, then re-submit via Step 17 and notify the assigned compliance contact
Rejected	Merchant cannot be onboarded under this tenant

⚠️
Website audit is a gating step
If the website audit fails, the wallet cannot be unbarred regardless of the screening outcome.

Step 19 — Unbar the wallet

Compliance clears the BARRED flag and the wallet becomes live for transactions. Only compliance-role users can perform this action.

Actor: Compliance

📎 API reference: Update a wallet by walletId — the underlying mechanism is a status update from BARRED to ACTIVE. Where the tenant property checkRatificationOnWalletStatusUpdateToActive is enabled, the KYC ruleset is re-checked at this point.

Wallet status flags

Value	Meaning
`BARRED = 2`	No transactions permitted — default for new merchant wallets
`ACTIVE = 0`	Transactions permitted
`CANCELLED = 1000`	Terminal state — cannot be re-activated

Step 20 — Confirm go-live

Verify wallet status is ACTIVE and notify the merchant.

Actor: Reseller

GET /eclipse-conductor/rest/v1/tenants/{tenantId}/wallets/{walletId}

📎 API reference: Get wallet by walletId

Verify status = 0 (ACTIVE).

📘
Retain these identifiers
organisationId, walletId, and the customerId of the primary contact are required for every future support, reporting, and configuration call. Store them against the merchant record in your own system.

Navigation

◀ Previous: Phase 5 — Automated Screening
▲ Overview: Merchant Acquiring Reseller
▶ Reference: Field, document, and code quick reference

Part of Merchant Acquiring Reseller — Phase 6 of 6 · Actors: Reseller / Merchant / Compliance

Step 16 — Merchant accepts the Terms & Conditions (digital)

First time only

Sandbox host

Step 17 — Submit for compliance review

Call this on first submission and on every re-review

Step 18 — Website audit and screening review

Website audit is a gating step

Step 19 — Unbar the wallet

Step 20 — Confirm go-live

Retain these identifiers

Navigation