Skip to main content

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

WooCommerce plugin

Download the latest .zip for WordPress.

PrestaShop module

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

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 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=<hex>, 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 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.