Skip to main content

Onramping API

This document covers the Onramping endpoint used to create pay-links that redirect your customers to our on-ramp checkout where they can purchase crypto with fiat and have it sent directly to a deposit address. It includes:
  • Create a pay-link (POST /api/ramping/links)
This endpoint is protected, you must be authenticated.

Base URL

All examples use:
  • https://www.niftipay.com
If you’re running locally, replace with your own base URL.

Authentication

This endpoint supports two authentication methods (depending on your integration setup): Send your API key in the x-api-key header.
If you are authenticated via the dashboard.
For browser calls, you usually don’t need to add headers manually — the cookie is sent automatically.

How it works

  1. You call POST /api/ramping/links with your customer’s details and the fiat amount.
  2. The API creates an underlying crypto invoice order and generates a signed pay-link token.
  3. You redirect your customer to the returned url.
  4. The customer lands on the Niftipay on-ramp page, selects a payment method (card or bank transfer), completes KYC if needed, and pays.
  5. The purchased crypto is sent directly to the invoice deposit address.
  6. Once the on-chain deposit is detected, the invoice is marked as paid and your webhook fires.

POST /api/ramping/links

Request body

If network and asset are not provided, the API will use your saved defaults from /api/ramping/settings-token. If no defaults are saved either, the request will fail with a 400 error.

Query parameters


Success response (200)

Response fields

url

The full public URL to redirect your customer to. This is the on-ramp checkout page.

order


Supported fiat currencies

The following fiat currencies are supported for on-ramping:
Availability of specific currencies may vary depending on the customer’s country and the on-ramp provider selected.

Bank approval rates

On-ramping is limited by the customer’s card-issuing bank. Each bank has a historic approval rate that determines how likely a card transaction is to succeed. See the full Bank Approval Rates reference for all supported banks and their approval percentages by region.

Error responses


Examples

Example 2 — With reference and merchant ID

Example 3 — Using saved defaults (no network/asset/fiat)

If you have already configured defaults via the dashboard or /api/ramping/settings-token:

Example 4 — Replace a cancelled order

If a previous order with the same reference was cancelled and you want to create a new one:

Customer flow after redirect

Once your customer opens the url returned by this endpoint:
  1. They see the on-ramp checkout page with the invoice details pre-filled.
  2. They enter their email (used for verification code and KYC).
  3. They select a payment method: Debit/Credit Card or Bank Transfer.
  4. They are redirected to complete KYC and payment.
  5. The crypto is purchased and sent to the invoice deposit address.
  6. Once the on-chain deposit is confirmed, the invoice status changes to paid.
The on-ramp provider is automatically selected based on the customer’s geolocation. You can override this with the provider field in the API request.

Node.js Example

A complete Node.js example showing how to create an onramping pay-link, including all optional fields and response parsing.
See the full working script with setup and helper function: API Examples (Node.js)

Webhooks

Ramping orders fire events on two channels, both delivered to your merchant webhook URL with the same HMAC signing scheme:
  • Core order events (pending, paid, cancelled, expired, refunded) track the underlying crypto invoice — the same events you receive for direct crypto orders.
  • Ramping events (ramping.status_changed, ramping.kyc_pending) track the onramp provider’s own lifecycle (KYC, fiat capture, status transitions).

Expiry behavior for Banxa orders

Crypto invoices created through the ramping flow get an initial expiresAt = createdAt + 12 hours, the same as direct invoices. Onramp orders behave differently when KYC is in progress:
  • If the linked Banxa order is still in a non-terminal status (e.g. extraVerification, pendingPayment, waitingPayment, paymentReceived) as the 12h mark approaches, Niftipay automatically extends the invoice’s expiresAt up to a 72-hour hard cap from the ramping order’s creation time and emits a ramping.kyc_pending event.
  • If KYC clears within 72h, funds are delivered on-chain and you receive the normal paid event.
  • If KYC does not clear within 72h, the invoice is force-cancelled and you receive an expired event with reason: "ramping_kyc_timeout" plus a final ramping.status_changed with reason: "kyc_timeout_72h".
See the full event reference and payload examples in the Webhooks documentation.