# Limits



Limits apply per user, not per integration:

* **Per transaction** — up to $9,999 CAD, buying or selling
* **Active transactions** — 3 open at a time
* **Cancelled or expired transactions** — 10 per 24 hours
* **Expiry** — buys expire after 1 hour, sells after 24 hours

## Value limits [#value-limits]

### Per transaction [#per-transaction]

<Callout type="info" title="Read limits from the API">
  Maximums can differ per account and change over time. Read them from [`GET /v2/limits`](/v2/api-reference/limits/getLimits) rather than hardcoding them — the endpoint returns the limits that apply to the authenticated user.
</Callout>

`GET /v2/limits` returns minimums and maximums keyed by the currency the user is paying with, converted at the current rate. The values below are illustrative:

```json
{
  "success": true,
  "data": {
    "leftSideCurrency": {
      "CAD": { "minimum": 100, "maximum": 9999 },
      "CADC": { "minimum": 103, "maximum": 9999 },
      "USDC": { "minimum": 78, "maximum": 7342.6 }
    }
  }
}
```

Stablecoin bounds are derived from the CAD maximum at the current rate, so they move between calls. Fetch them rather than caching them.

### Minimums [#minimums]

The `minimum&#x60; values above are the self-serve minimums applied in Paytrie's own interface. Transactions created through the Platform API are accepted down to **$10 CAD** for both USDC and CADC.

<Card title="API Reference: Get minimum and maximum limits per currency" href="/v2/api-reference/limits/getLimits" icon="gauge">
  View the response schema
</Card>

### Interac limits [#interac-limits]

Buy transactions are funded by Interac e-Transfer, and each bank sets its own sending limits — frequently lower than Paytrie's maximum, and sometimes lower per transfer than per day. A transaction accepted by Paytrie can still be refused by the user's bank, so surface Paytrie's limit as a ceiling rather than a guarantee.

## Transaction count limits [#transaction-count-limits]

A transaction is **active** until it reaches one of the final [transaction statuses](/v2/transactions#transaction-statuses). Only transactions created in the last 24 hours count toward this limit.

The cancellation limit counts cancelled **and** expired transactions together. A user who lets ten buy transactions time out unfunded is blocked just as if they had cancelled ten, so avoid creating speculative transactions the user may not complete.

## Expiry [#expiry]

Expiry is measured from when the transaction was created. A buy expires if the user's Interac e-Transfer has not been received within an hour; a sell expires if the user's stablecoin transfer has not arrived within a day. Transactions already being processed are never expired.

Expiry is applied in the background, so a transaction can stay visible for a short period past its window before its status changes to `expired`. Subscribe to [webhooks](/v2/webhooks) to be notified when it does, rather than timing it yourself.

## Error responses [#error-responses]

A transaction blocked by any of these limits is rejected with a `400` and an error message describing which limit was hit. Display the message rather than matching on it — the wording is written for end users and is subject to change, so branch on the status code instead.

These are user-recoverable states rather than integration faults. Depending on the limit, the user can lower the amount, complete or cancel an open transaction, or wait for the 24-hour window to move. If a user is repeatedly blocked in a way that looks wrong, [contact support](/v2/support).
