Developers / Integration model

From first request to verified event.

Follow the target integration from a workspace-scoped server credential to authoritative transfer state and lifecycle Events delivered through signed webhooks.

View the integration model Understand Webhook Delivery

WORKSPACE SCOPED Server credential
RETRY SAFE Idempotent financial commands
AT LEAST ONCE Signed Webhook Deliveries

ILLUSTRATIVE REQUEST / CREATE USER PRODUCT MODEL

Illustrative integration model. Exact routes, credentials, request and response schemas, Event types, delivery headers, and signing rules will be synchronized with the standalone API contract before launch.

POST {USER_COLLECTION_ROUTE}
{WORKSPACE_CREDENTIAL_HEADER}: {WORKSPACE_KEY}
{IDEMPOTENCY_HEADER}: {ONE_INTENT_KEY}

{
    "external_id": "customer_1842"
}

REFERENCE OUTCOME user + default account

{
  "user": {
    "id": "user_example",
    "external_id": "customer_1842"
  },
  "default_account": {
    "id": "account_example",
    "status": "provisioning"
  }
}

Scope: One workspace
Account: Created automatically
Money effect: None

01 / Target integration

The target path to a usable deposit destination.

Your users stay in your product. The processing model creates the user and default account together, provisions that account asynchronously, then creates the asset wallet and permanent destination only after the account is ready.

01

AUTHENTICATE
Use a workspace credential

Keep the revocable credential on your server. It resolves every request to exactly one workspace.

credential → workspace
02

CREATE
Create the external user

Supply your immutable identifier; the product creates the user and one default account as one durable outcome.

user + default account
03

WAIT
Read account readiness

The account is provisioned asynchronously. Reuse the same account through retries until it becomes ready.

provisioning → ready
04

PROVISION
Create the asset wallet

For a ready account, create one wallet for an economic asset. For example, a USDT wallet can expose permanent destinations on Tron and Ethereum.

USDT example → Tron + Ethereum

Illustrative integration model. Exact routes, schemas, Event types, delivery headers, and signing rules will be defined in the standalone external contract and synchronized before launch.

02 / Idempotent commands

Make one intent safe to retry.

Attach one stable idempotency identity to each mutating command. If the outcome is unknown, repeat the same intent and payload, then read the original resource instead of creating a second financial effect.

Credentials stay server-side

Never expose a workspace credential in a browser or mobile client.

One identity represents one intent

Reuse it only for the same command and payload; a different intent needs a different identity.

REFERENCE IDEMPOTENCY FLOW intent: withdrawal_example

01
FIRST ATTEMPT submit withdrawal intent
OPERATION CREATED
02
CONNECTION LOST client outcome unknown
OUTCOME UNKNOWN
03
SAFE RETRY same intent identity + payload
ORIGINAL OPERATION

DURABLE OPERATIONS 01

MONEY EFFECTS 01

REFERENCE OUTCOME

03 / Events and Webhook Delivery

Verify each delivery. Deduplicate each Event.

A durable Event exists independently of its Webhook Deliveries. Delivery is at least once: each retry carries the same Event identity, so verify origin and freshness, deduplicate the Event, and keep the product read model authoritative.

ILLUSTRATIVE EVENT ENVELOPE event_example

{
  "id": "event_example",
  "type": "{EVENT_TYPE}",
  "created_at": "2030-01-01T10:24:31Z",
  "data": {
    "resource_type": "{RESOURCE_KIND}",
    "resource_id": "{RESOURCE_ID}",
    "state": "completed"
  }
}

DELIVERED WITH SIGNATURE contract-defined headers

HANDLER CHECKLIST Before returning success

01
Preserve verification input Use the exact content and delivery metadata required by the finalized contract.
02
Verify the Delivery Check signature, freshness, and delivery identity before trusting the transport.
03
Deduplicate the Event ID A retry creates another Delivery for the same Event, not another business action.
04
Persist idempotently Record the Event result before acknowledging the Delivery.

REFERENCE FLOW verify → dedupe → persist → acknowledge

04 / Authoritative state

Use Events as notifications, reads as authority.

A Webhook Delivery tells your system that a validated product fact exists. When a request or delivery outcome is uncertain, read the corresponding resource instead of inferring financial state from transport behavior.

Authoritative-state guidance
Signal	Meaning	Consumer rule
Write response	Current result of one command.	Persist the returned resource identity.
Transfer read	Authoritative public state.	Use it for recovery and confirmation.
Event	Durable validated product fact.	Deduplicate by Event ID.
Webhook Delivery	At-least-once transport attempt.	A retry is not a new Event.

Managed evaluation

Review the target integration with PSPTech.

Review the platform Discuss your use case

From first request to verified event.

The target path to a usable deposit destination.

Use a workspace credential

Create the external user