Testing conversions

When you build on the Conversion rules API, a rule only fires when a matching deposit lands on its provisioned inbound endpoint. In the sandbox that means you would otherwise have to send a real bank transfer or an on-chain transaction to see a conversion transaction appear. The simulate deposit endpoint removes that step: it injects a test deposit against an existing rule so you can verify your integration (rule creation, transaction polling, and your own reconciliation logic) without moving any real funds.

Sandbox only. Simulated deposits are a testing aid for the sandbox environment. They do not move funds and are not available in production. Use them to validate your integration’s wiring, not to test real settlement.

Crypto testnets: real on-chain flow. For supported crypto networks, the sandbox can be backed by network testnets, so you can make real testnet deposits and withdrawals against a conversion rule and exercise the actual on-chain legs end to end rather than simulating them. Which networks and testnets are enabled for your sandbox depends on your setup. Contact your Payward integration engineer for the current list and the testnet faucet/funding details.

How it works

You simulate a deposit against a conversion rule you have already created. PWS resolves the rule’s inbound routing internally and submits a test deposit for the amount you specify: exactly as if a matching credit had arrived on the rule’s from endpoint. The rule fires and produces a new conversion transaction, which you then monitor through the normal transactions endpoint. The end-to-end flow is three steps:

Create a conversion rule: the standing from → to configuration you want to test.
Simulate a deposit against that rule.
Poll the rule’s transactions to watch the conversion progress to completed.

The curl examples read these environment variables:

PWS_BASE_URL: the API base URL. Set it to the sandbox or production base URL, listed in Environments.
PWS_API_KEY: your API key.
PWS_API_TIMESTAMP and PWS_API_SIGN: the timestamp and signature of each request. To compute them, see Authentication.
Compute PWS_API_SIGN over the exact -d string, including its line breaks and indentation, and over the exact path and query in the URL. Each request needs a new PWS_API_TIMESTAMP and PWS_API_SIGN.

Step 1: Create a conversion rule

Create the rule you want to exercise. This is the standard create call described in Conversion rules: here, a EUR on-ramp settling USDC to a Polygon wallet:

curl -X POST "$PWS_BASE_URL/v1/accounts/AA23N84GGQN4WE6I/conversions" \
  -H "API-Key: $PWS_API_KEY" \
  -H "API-Timestamp: $PWS_API_TIMESTAMP" \
  -H "API-Sign: $PWS_API_SIGN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "EUR autoramp to Polygon vault",
    "from": {
      "symbol": "EUR",
      "type": "bank",
      "bank_account": { "via": "sepa" }
    },
    "to": {
      "symbol": "USDC",
      "type": "wallet",
      "wallet": {
        "via": "polygon",
        "address": "0x1234567890abcdef1234567890abcdef12345678"
      }
    }
  }'

The full rule is returned (from, to, and timestamps included; see Conversion rules). Note the id: you need it as the conversion_id in the next step:

{
  "data": {
    "id": "550e8400-e29b-41d4-a716-446655440000",
    "name": "EUR autoramp to Polygon vault",
    "status": "active"
  }
}

Wait for active. Simulate a deposit only once the rule is active. If the rule is still provisioning, its inbound endpoint is not ready: fetch it with GET /v1/accounts/{account_id}/conversions/{conversion_id} until the status is active.

Step 2: Simulate a deposit

Submit a test deposit against the rule with POST /v1/accounts/{account_id}/conversions/{conversion_id}/testing/deposit. The amount is the value to simulate as received on the rule’s inbound side, in the source asset (EUR, for the rule above):

curl -X POST "$PWS_BASE_URL/v1/accounts/AA23N84GGQN4WE6I/conversions/550e8400-e29b-41d4-a716-446655440000/testing/deposit" \
  -H "API-Key: $PWS_API_KEY" \
  -H "API-Timestamp: $PWS_API_TIMESTAMP" \
  -H "API-Sign: $PWS_API_SIGN" \
  -H "Content-Type: application/json" \
  -d '{
    "amount": "100.00",
    "name": "Jane Doe"
  }'

Field	Required	Description
`amount`	Yes	Positive decimal string to simulate as received on the rule’s inbound, in the `from` asset. No surrounding whitespace.
`name`	No	Fiat only. Simulates the name on the sending account as reported by the bank provider. Use it to exercise your internal risk checks, for example name-match logic between the remitter and the account holder. Has no effect on crypto inbounds.

The response confirms only that PWS accepted the simulated deposit for processing. It does not mean the conversion has completed:

{ "data": { "simulated": true } }

A simulated: true response means the test deposit was submitted upstream and the rule will fire. The resulting conversion transaction settles asynchronously; observe its progress in step 3.

amount is a string. Send the amount as a JSON string ("100.00"), not a number, and trim any surrounding whitespace. A non-positive or whitespace-padded value is rejected with 400.

Step 3: Watch the conversion transaction

The simulated deposit produces a conversion transaction just like a real deposit would. Poll the rule’s transactions to watch it move from pending_deposit through to completed:

curl -X GET "$PWS_BASE_URL/v1/accounts/AA23N84GGQN4WE6I/conversions/550e8400-e29b-41d4-a716-446655440000/transactions" \
  -H "API-Key: $PWS_API_KEY" \
  -H "API-Timestamp: $PWS_API_TIMESTAMP" \
  -H "API-Sign: $PWS_API_SIGN"

{
  "data": [
    {
      "id": "conv_smoke_001",
      "status": "completed",
      "conversion_rule_id": "550e8400-e29b-41d4-a716-446655440000",
      "from": { "asset_symbol": "EUR", "asset_amount": "100.00", "source_type": "bank", "source_via": "sepa" },
      "to": { "asset_symbol": "USDC", "asset_amount": "108.42" },
      "chain_references": { "withdraw_txid": "withdraw-usdc-001" },
      "created_at": "2026-04-01T12:00:00Z"
    }
  ]
}

The transaction moves through the same lifecycle as a production conversion (pending_deposit → converting → settling → completed). See Monitoring conversions for the full state table.

Webhooks. A simulated deposit emits the same conversion webhook events as a real one (conversion.deposit_completed, conversion.deposit_held, conversion.withdrawal_completed, and the rest), so you can use it to test your webhook handler end to end. Register your endpoint with the Register Webhook API. You can also follow the simulated conversion by polling the transactions endpoint, exactly as in production.

API reference

Method	Endpoint	Description
POST	`/v1/accounts/{account_id}/conversions/{conversion_id}/testing/deposit`	Simulate an inbound deposit against a rule (sandbox)
GET	`/v1/accounts/{account_id}/conversions/{conversion_id}/transactions`	List the transactions produced by a rule

Introduction

Testing

Market data

Accounts

Verifications

Trade

Earn

Payments

How it works

Step 1: Create a conversion rule

Step 2: Simulate a deposit

Step 3: Watch the conversion transaction

API reference

​How it works

​Step 1: Create a conversion rule

​Step 2: Simulate a deposit

​Step 3: Watch the conversion transaction

​API reference

How it works

Step 1: Create a conversion rule

Step 2: Simulate a deposit

Step 3: Watch the conversion transaction

API reference