Payments - payment acceptance (Fiat + Crypto)
Info
Payments is the layer that turns Business into a “revenue loop”: accept payments, credit funds, close documents, reflect them in accounting, and scale without chaos.
Module logic and boundaries of responsibility
Payments is responsible for accepting funds and payment statuses. Business turns these statuses into managed processes: roles, documents, accounting, integrations, and control.
The Payments module solves a simple task that in practice always becomes complex: accept a payment quickly, predictably, and securely, and then bring it to a business-understandable outcome - crediting, receipt, closed invoice, and a clear export into accounting.
To prevent the system from spreading uncontrollably, we separate the layers:
- Payments - payment acceptance, statuses, refunds, anti-fraud at acceptance, settlement.
- Business - company management: roles and permissions, approvals, accounting and reconciliation, reports, documents, and integrations.
This separation reduces fragmentation for the client and lowers engineering risk for the platform: each layer is responsible for its own outcome and does not break the other.
Note
Payments does not exist “on its own”. It strengthens Business and becomes the entry point of funds into the corporate loop, where documents, roles, audit, and reporting are then activated.
Rollout order: online first, then offline
We start with online payments as the most scalable scenario. Offline devices are added later, once risks and processes are already under control.
The rollout begins with online payments (checkout), because this is the fastest way to onboard businesses, test conversion, and build a mature model of statuses, refunds, and anti-fraud.
Then the module expands into the physical world:
- accepting payments offline through devices and POS scenarios
- a unified merchant dashboard and unified statuses, regardless of channel
In the long-term roadmap, a limited offline mode is provided for terminals and our cards: payments are possible without constant internet access, but with mandatory synchronization and strict risk policies.
Warning
Offline mode must not reduce security. Therefore, it is enabled only under strict limits, transparent auditing, and mandatory status synchronization.
Online payments: a single checkout for fiat and crypto
A single payment acceptance point for websites and applications: fiat methods and cryptocurrency in one flow, with clear statuses and receipts.
Online payments are not a simple “Pay” button, but a managed payment object with a status and lifecycle. The merchant gets a single tool that covers more customers and reduces losses caused by errors.
Key modes:
- checkout for website/application
- payment link (link to pay)
- QR (where appropriate): static for fast scenarios and dynamic per amount/invoice
The technical foundation is an API and event delivery via Webhook, so that payments automatically become part of Business processes.
Tip
A unified checkout reduces fragmentation: the business does not need to maintain “fiat separately” and “crypto separately” - different rails operate within a single model of statuses and documents.
Crypto payments: address, statuses, error protection
For crypto payments, a payment object is created with a unique address, a lifetime, and strict parameter validation to reduce network and amount errors.
In the crypto payment flow, the buyer receives a payment address and clear payment parameters. This is not “just an address”, but an object that can be matched, verified, and closed with a correct status.
Base model:
- a unique address for a specific payment
- TTL (time to live) and rules for handling expired payments
- status chain: created - pending - detected - confirmed - credited - error
Error-prevention layer:
- explicit network selection and fee guidance
- warnings when there is a risk of using the wrong network
- rules for handling incorrect amounts and partial payments
- a transparent policy for resolving non-standard cases, so that there are no “lost payments”
Example
The buyer pays with cryptocurrency - they see the address and the network. After sending, the status changes to “detected”, then to “confirmed”, and only after that the payment is considered completed and appears in the merchant’s accounting.
One-tap for DARCA users: one-click payments
If the payer is inside DARCA, the payment becomes a standard object: choose the source (fiat or crypto) and confirm in one click, without manual addresses or errors.
The main growth driver of the module is the mode where both the payer and the merchant are inside DARCA. In this case, the payment looks like a regular invoice: tap, choose the source, confirm.
Advantages of one-tap:
- fewer network and payment detail errors
- higher payment conversion
- less load on support
- payments can be commission-free or have minimal costs where there are no external rails
This becomes a point of attraction: it is beneficial for merchants when customers pay from DARCA, and it is beneficial for customers to become DARCA users in order to pay more easily.
Info
One-tap is both UX and risk control: fewer manual actions, fewer disputed situations, fewer “accidental” errors.
Settlement: where revenue is credited and how fast
The merchant configures what to receive: fiat, stable, or crypto. Inside the ecosystem, settlement can be instant; outside, it follows the rules of the rail and the region.
In Payments, it is important not to promise “always instant”, but to ensure predictability. Therefore, settlement is described as a set of modes:
- crediting to fiat
- crediting to stable (Stablecoin)
- crediting to crypto
Where possible, the final “you pay / you receive” is shown before confirmation - with no hidden fees or unpleasant surprises. With card payments, there is no additional confirmation after payment, so the final amount must be clear on the checkout screen before clicking “Pay”.
Note
Predictability is more important than “the best rate at the moment”. Therefore, conversion rules and the final amount must be transparent and repeatable.
Merchant dashboard: statuses, refunds, documents
The dashboard must answer three questions: what was paid, what was credited, and what requires action. Everything else is a consequence of a mature status model.
The base merchant dashboard includes:
- a payment feed with statuses and decline reasons
- refunds and partial refunds
- receipts and exports
- registers for reconciliation and accounting
A strong differentiator of DARCA is the connection with Business: payments automatically “close” accounting objects and reduce manual work.
Warning
If refunds and disputes are not designed as a process with statuses, they turn into a reputational sink. That is why a refund is an object, not a conversation.
Integrations: API, webhooks, connection security
Integrations turn Payments into infrastructure: payment events automatically flow into accounting and processes, while access is protected by scopes, audit trails, and cryptography.
Integrations are built on:
- API for creating payments, retrieving statuses, and processing refunds
- Webhook for events, so businesses do not have to manually poll for statuses
- signed webhooks and integrity verification
- access scopes, key rotation, IP allowlists (for enterprise)
- access and action auditing
This directly addresses the problem of “legacy IT” and reduces fragmentation: payment events go straight into accounting, CRM, and ERP, without manual reconciliation.
Tip
Technical discipline in integrations is not a “feature”, but a way to avoid incidents and claims at the moment of growth.
Physical payment acceptance and limited offline mode
After the online layer, offline is added: POS and devices. In the long term - a mode without constant internet connectivity, with synchronization and strict limits.
Offline acceptance extends Payments to retail and services where checkout speed is critical. In the long-term strategy, terminals and our cards support a “no constant internet” mode:
- transactions are allowed within predefined limits and the risk profile
- the device stores protected transaction parameters
- statuses are finalized only after synchronization
Offline security is reinforced by hardware components and policies that can rely on the Enhanced Security module and corporate risk settings.
Danger
Offline is only possible as a controlled extension: limits, audit, synchronization, monitoring. Otherwise, it turns into a risk of double spending and a reputational hit.
Monetization: how the module earns and scales
Payments generates revenue from transactions, conversion and subscriptions, and also strengthens the entire ecosystem through volume and customer inflow via merchants.
The revenue model is multi-layered and scales without aggressive fees:
- fees for payment acceptance (fiat and crypto), where part may be partner costs
- conversion revenue (fiat - crypto - stable) when the user selects the settlement option
- business subscriptions: limits, lower fees, advanced analytics, dispute tools, SLA, additional integrations
- paid enterprise integrations and API extensions
Secondary effect:
- more merchants - more reasons to pay via DARCA
- more payments - more volume inside the ecosystem
- more volume - higher retention and conversion into other products
Info
Payments creates a “growth loop”: merchants bring users, users generate volume, and volume makes merchants even more interested in connecting.
Risks and risk management
Payments require a mature risk model: KYB, antifraud, statuses, reserves, refunds and controlled regional restrictions.
Key risks and management layers:
- payer fraud and refunds, including Chargeback in fiat
- merchant fraud and “grey” turnover - mandatory KYB (in the corporate variant) and pattern monitoring
- crypto payment errors (wrong network, wrong amount) - object-based payment model, TTL, validations and case-handling rules
- partner infrastructure risks - operation idempotency, event queues, transparent statuses and reasons
- regional restrictions - feature gating and tiered access to avoid enabling prohibited functionality
The platform applies a risk-based approach:
- limits and holds for new participants
- expansion of capabilities based on history
- controlled hold scenarios for suspicious situations
Warning
In payments, the goal is not “never making mistakes”, but always having a controllable status, a clear reason, an audit trail and a predictable resolution process.
Connection with the DARCA ecosystem
Payments strengthens Business and the Core: it simplifies payment acceptance, reduces fragmentation and drives user inflow through convenient one-tap scenarios.
Connection with key layers:
- Business - invoices and documents are closed by payment statuses, roles and audit control settings and refunds
- Core - transparent exchanges and transfers support predictable outcomes and minimize surprises
- P2P - secure settlements and fast internal transfers create liquidity and the habit of “doing operations inside”
- Enhanced Security - risk policies, confirmations, geo rules and access control strengthen the merchant layer
Result: Payments is not just “another feature”. It is an infrastructure layer that makes the ecosystem cohesive, reduces fragmentation and creates a scalable customer flow through a real everyday need - payments.
Tip
The more businesses accept payments via DARCA, the stronger the network effect: customers come “for a task”, stay “for convenience”, and expand their use of the ecosystem.