CRYPTO PROCESSING
View integration model Discuss your use case

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.

  1. 01
    AUTHENTICATE

    Use a workspace credential

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

    credential → workspace
  2. 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
  3. 03
    WAIT

    Read account readiness

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

    provisioning → ready
  4. 04
    PROVISION

    Create the asset wallet

    For a ready account, create one wallet for an economic asset and permanent destinations on supported networks.

    wallet → permanent destination

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
  1. 01
    FIRST ATTEMPT submit withdrawal intent
    OPERATION CREATED
  2. 02
    CONNECTION LOST client outcome unknown
    OUTCOME UNKNOWN
  3. 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
  1. 01
    Preserve verification input Use the exact content and delivery metadata required by the finalized contract.
  2. 02
    Verify the Delivery Check signature, freshness, and delivery identity before trusting the transport.
  3. 03
    Deduplicate the Event ID A retry creates another Delivery for the same Event, not another business action.
  4. 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