Skip to main content

Fiat Module

Note: all numeric values, amounts, rates, and identifiers in the examples are illustrative and provided for demonstration purposes only. Real values depend on market conditions, account configuration, and the parameters of a specific transaction.

Overview

Fiat Module is a subsystem of the CryptoCash platform that allows a merchant to accept fiat payments from end users and receive cryptocurrency to their wallet. Integration is performed through signed API requests. Payments are processed via a payment provider (Mercuryo). The end user completes the payment in the CryptoCash widget, where they select a payment method. After the payment is processed, the merchant receives a webhook with the final status. Supported features:
  • Payment by card, Apple Pay, Google Pay, SEPA, and other payment methods
  • Signed requests (ED25519 or LEGACY/SHA256) for merchant authentication
  • Webhooks to the merchant on every transaction status change
  • Automatic calculation of the merchant’s earnings based on partner_fee

High-level flow

Two payment flows in the widget: For a detailed description of the native Apple Pay flow, see the Apple Native Pay section.

Merchant setup and Fiat API Key

What the merchant configures

After the administrator has prepared the account, the merchant generates a Fiat API Key in the dashboard. When creating the key, the merchant sets parameters that apply to all payments associated with this key: The response returns a publicKey / privateKey pair. The private key is stored on the platform in encrypted form and is shown to the merchant only once — during creation. Save it immediately.
If two-factor authentication is enabled on the merchant account, 2FA confirmation is required to generate the key.

Fiat API Key fields

ED25519 vs LEGACY

What is checked on each request

When receiving a signed request, the platform checks:
  • The key is active
  • The key has not expired
  • The IP of the API caller (merchant server) is included in the allowed list if IP restriction is enabled
  • The signature is valid for the selected algorithm
Important: IP restriction applies to the address of the server making the API request, not to the end user’s IP in the payment payload ip field.

Signed requests

All merchant API requests must be signed. The signature algorithm is defined by the keyType value selected when creating the key.

Request structure

publicKey is passed either in the x-public-key header or inside the data object. If both are present, the header takes priority.

LEGACY (SHA256)

Full example

Payload for form/retrieve:
Final body of the signed request:

Payment creation — form/retrieve

Endpoint

Signed request. The signature and IP are checked before the request is processed.

Request

The data field of the signed request contains the following JSON: * To select a crypto asset, pass either ticker or the currency + network pair.

Response

What happens after the request

  1. Signature and IP are checked.
  2. externalId uniqueness is checked within the merchant key.
  3. The fiat amount is checked against the minimum allowed amount for the selected currency.
  4. The network value is normalized case-insensitively.
  5. A transaction is created with the New status.
  6. The widget URL is generated.
  7. A payment::created webhook is sent to the merchant.
  8. id and url are returned.

CryptoCash widget and provider page

The merchant always receives the CryptoCash widget URL. The provider page URL is generated inside the widget after the payment method is selected and is not returned to the merchant.

Merchant Public API

Retrieve payment

Signed request. The data field contains one of the following:
or
Response:

Payment list

Signed request. The data field: Response:

Currency lists

Both endpoints use signed requests. Minimum payload in data:
crypto-currencies/list returns the cryptocurrencies available to the merchant together with networks and tickers. Values from tickers can be passed to form/retrieve instead of the currency + network pair.

Payment response fields

Transaction statuses

Statuses are set by the platform based on payment provider events. The merchant cannot change the status via API.

Error handling

All API errors are returned in one of two formats: Format A — coded error:
Format B — error list used for decoding errors:

Error codes

Apple Pay

The CryptoCash widget supports the native Apple Pay flow: the iOS payment sheet opens directly in the widget without redirecting to an external page. For a detailed description of native mode availability conditions, fallback behavior, and error handling, see the Apple Native Pay section.

Diagrams

General payment flow