> ## Documentation Index
> Fetch the complete documentation index at: https://docs.services.payward.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Testing conversions

> Exercise a conversion rule end to end in the sandbox by simulating an inbound deposit — no real bank transfer or on-chain send required.

When you build on the [Conversions API](/tabs/developer-documentation/payments/conversions), 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.

<Note>
  **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.
</Note>

<Note>
  **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.
</Note>

## 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:

1. **Create a conversion rule** — the standing `from` → `to` configuration you want to test.
2. **Simulate a deposit** against that rule.
3. **Poll the rule's transactions** to watch the conversion progress to `completed`.

## Step 1 — Create a conversion rule

Create the rule you want to exercise. This is the standard create call described in [Conversions](/tabs/developer-documentation/payments/conversions) — here, a EUR on-ramp settling USDC to a Polygon wallet:

```bash theme={null}
curl -X POST "https://api.services.payward.com/v1/accounts/AA23N84GGQN4WE6I/conversions" \
  -H "API-Key: $PWS_API_KEY" \
  -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 [Conversions](/tabs/developer-documentation/payments/conversions#creating-a-rule--fiat-on-ramp-eur--usdc-on-polygon)). Note the `id` — you need it as the `conversion_id` in the next step:

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

<Note>
  **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`.
</Note>

## 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):

```bash theme={null}
curl -X POST "https://api.services.payward.com/v1/accounts/AA23N84GGQN4WE6I/conversions/550e8400-e29b-41d4-a716-446655440000/testing/deposit" \
  -H "API-Key: $PWS_API_KEY" \
  -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 — not that the conversion has completed:

```json theme={null}
{ "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.

<Note>
  **`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`.
</Note>

## 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`:

```bash theme={null}
curl -X GET "https://api.services.payward.com/v1/accounts/AA23N84GGQN4WE6I/conversions/550e8400-e29b-41d4-a716-446655440000/transactions" \
  -H "API-Key: $PWS_API_KEY" \
  -H "API-Sign: $PWS_API_SIGN"
```

```json theme={null}
{
  "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](/tabs/developer-documentation/payments/conversions#monitoring-conversions) for the full state table.

<Note>
  **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-reference/webhooks/register-webhook) API. You can also follow the simulated conversion by polling the
  transactions endpoint, exactly as in production.
</Note>

## API reference

| 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             |