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 (
ED25519orLEGACY/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
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 thekeyType 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.
ED25519 (recommended)
LEGACY (SHA256)
Full example
Payload forform/retrieve:
Payment creation — form/retrieve
Endpoint
Request
Thedata 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
- Signature and IP are checked.
externalIduniqueness is checked within the merchant key.- The fiat amount is checked against the minimum allowed amount for the selected currency.
- The
networkvalue is normalized case-insensitively. - A transaction is created with the
Newstatus. - The widget URL is generated.
- A
payment::createdwebhook is sent to the merchant. idandurlare 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
data field contains one of the following:
Payment list
data field:
Response:
Currency lists
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.