> ## Documentation Index
> Fetch the complete documentation index at: https://www.niftipay.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# E-commerce Plugins
> NiftiPay plugins for WooCommerce and PrestaShop — payment methods, credentials, webhooks, return URLs, and the card fee-payer setting they share.
# E-commerce plugins
Drop-in plugins that let a shop take NiftiPay payments without writing any
integration code. Two exist today and they are feature-equivalent:
| Plugin | Platform | Guide | Download |
| ------------------------ | ---------------------------------- | ----------------------------------- | ---------------------------------------------------------------------------------------------- |
| NiftiPay for WooCommerce | WordPress ≥ 6.2, WooCommerce ≥ 6.0 | [WooCommerce](/docs/plugins/woocommerce) | [Download](https://drive.google.com/file/d/19u5S9eUtE1AXMPBxRY6sdgL_79XEk5Ov/view?usp=sharing) |
| NiftiPay for PrestaShop | PrestaShop 1.7+ | [PrestaShop](/docs/plugins/prestashop) | [Download](https://drive.google.com/file/d/1nsvJvp-9wivtKUPppcNb-TDJvIGk222V/view?usp=sharing) |
Download the latest `.zip` for WordPress.
Download the latest `.zip` for PrestaShop.
This page covers what both share. The per-plugin guides cover installation,
settings, and platform-specific behaviour.
***
## Payment methods
Each plugin exposes the same three methods, individually enableable:
| Method | Customer experience | Endpoint used |
| --------------- | ------------------------------------------------------------------------------------- | ------------------------- |
| **Crypto** | Invoice with QR + countdown rendered on your own confirmation page, polled until paid | `POST /api/orders` |
| **Fiat (card)** | Redirect to the NiftiPay-hosted card page, then back to your shop | `POST /api/fiat/orders` |
| **Ramping** | Redirect to a Banxa-backed buy-crypto-and-pay flow | `POST /api/ramping/links` |
A method only appears at checkout when **all** of these hold:
1. it is enabled in the plugin settings;
2. it is enabled on your NiftiPay account (`GET /api/payment-methods`, cached
15 minutes by the plugin);
3. the cart total is within the per-currency min/max you configured for it.
## Credentials
| Value | Where to get it | Used for |
| ------------------ | ------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------- |
| **API key** | Dashboard → Settings → API Keys | `x-api-key` on every call the plugin makes |
| **Integration ID** | Dashboard → Settings → Fiat → *Integrations* → **Copy ID** ([how](/docs/api/fiat-orders#how-to-get-your-integrationid)) | Scopes orders to one shop; sent as `integrationId` |
| **Webhook secret** | Shown when you register the webhook URL | Verifying incoming webhooks |
Use **one integration per shop**. If you run several shops, create several
integrations and bind a webhook to each — otherwise every shop receives every
other shop's events. See [Webhooks](/docs/api/webhooks) for the scoping rules.
## Webhooks
The plugin exposes a public endpoint; you paste that URL into the dashboard.
Both plugins accept two auth schemes, in this order:
1. **HMAC signature (preferred).** Headers `x-signature: v1=`,
`x-timestamp`, `x-webhook-id`. The signed payload is
`HMAC_SHA256("{timestamp}.{rawBody}", secret)`, compared in constant time.
When `x-webhook-id` is present the plugin looks up the per-webhook secret, so
several integrations can safely post to one shop.
2. **Legacy shared secret.** `x-webhook-secret` header, or the secret in the
JSON body.
Unauthenticated requests get `401`. Handled events: `paid`, `pending`,
`underpaid`, `cancelled`, `expired`, `refunded`, plus `risk_alert` (logged, no
order change).
Transitions are guarded: a `cancelled` event never downgrades an already-paid
order, and a payment arriving after cancellation is flagged as **late paid**
with a note on the order instead of silently changing state.
## Return and failure URLs
Each plugin sends a **per-order** `returnUrl` with the order-creation call, and
NiftiPay redirects there once the payment page hands the customer back. Two
modes:
The plugin sends the order's own confirmation URL, including the order key,
so the customer lands on a real order page with their order details.
The plugin sends the URL configured in its settings — use this only if you
have a dedicated landing page.
The per-order value takes precedence over the integration's `returnUrl`.
`failureUrl` follows the same rule; when unset, the integration default applies.
Both must be `http(s)` URLs, otherwise NiftiPay falls back to the integration
default.
## Card service fee payer
Who absorbs the card processing fee is a **shared setting**. The source of truth
is your account default (`GET` / `PATCH /api/fiat/settings`,
`serviceFeePayerDefault`):
* `customer` — the fee is added on top, so the customer is charged more than the
shop order total.
* `merchant` — the fee is deducted from your payout; the customer pays the order
total exactly.
Both plugins push the value when you save it, pull it when you open the settings
page, and re-read it at checkout behind a 5-minute cache. Changing it in the
NiftiPay dashboard changes it in your shop, and vice versa. If NiftiPay is
unreachable, the plugin falls back to its last known local value.
## Refunds and risk tooling
From your shop's own order screen:
* **Crypto** — supply a refund address; `POST /api/orders/{id}/refunds`.
* **Fiat** — cancel-or-refund via `DELETE /api/fiat/orders/{key}`; NiftiPay
picks cancellation or refund based on the order's stage.
* **Fraud signals / IP risk** — `GET /api/fiat/orders/{key}/fraud-signals`
renders a risk score, reasons, and chargeback history for the payer's IP. See
[Fraud prevention](/docs/api/fraud-prevention).