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
Authentication
This endpoint supports two authentication methods (depending on your integration setup):1) API Key (recommended for server-to-server integrations)
Send your API key in thex-api-key header.
2) Session cookie (browser / dashboard usage)
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
- You call
POST /api/ramping/linkswith your customer’s details and the fiat amount. - The API creates an underlying crypto invoice order and generates a signed pay-link token.
- You redirect your customer to the returned
url. - The customer lands on the Niftipay on-ramp page, selects a payment method (card or bank transfer), completes KYC if needed, and pays.
- The purchased crypto is sent directly to the invoice deposit address.
- Once the on-chain deposit is detected, the invoice is marked as
paidand your webhook fires.
Create a pay-link
POST /api/ramping/links
Request body
Ifnetworkandassetare 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
link
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 1 — Basic pay-link (EUR, ETH network)
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 theurl returned by this endpoint:
- They see the on-ramp checkout page with the invoice details pre-filled.
- They enter their email (used for verification code and KYC).
- They select a payment method: Debit/Credit Card or Bank Transfer.
- They are redirected to complete KYC and payment.
- The crypto is purchased and sent to the invoice deposit address.
- 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 initialexpiresAt = 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’sexpiresAtup to a 72-hour hard cap from the ramping order’s creation time and emits aramping.kyc_pendingevent. - If KYC clears within 72h, funds are delivered on-chain and you receive the normal
paidevent. - If KYC does not clear within 72h, the invoice is force-cancelled and you receive an
expiredevent withreason: "ramping_kyc_timeout"plus a finalramping.status_changedwithreason: "kyc_timeout_72h".