built for the businesses
where payments matter most

1. casino

licensed casino operators face two hard constraints: regulators want full audit trails, and players hate slow withdrawals. HalcoPay fits both.

• instant payouts — once the player wins and you approve, the payout hits the chain within one block. no batch windows.
• no chargebacks — crypto payments are final. the dispute risk you absorb on cards goes to zero.
• regulator-ready — every invoice, payment method, and payout writes an immutable on-chain receipt plus an internal audit row. exportable as csv or via api.
• per-game wallets — isolate poker, slots, and live tables into separate wallets so reporting per product line is one query.

configuration notes: enable the PAYOUT_MANAGEMENT scope for the floor manager, the METRICS_MANAGEMENT scope for compliance.

2. igaming

igaming is a higher-velocity cousin of casino: smaller stakes, more transactions, customers from many jurisdictions, deposits and withdrawals on demand.

• low-friction deposits — the checkout supports every chain we run. the player picks one, a fresh address is generated, the deposit is credited the moment the chain confirms.
• withdrawals as a batch or one-shot — operators can drain pending withdrawals to a single transaction (lower fees) or wire them individually (faster ux).
• multi-currency by default — quote in usd, settle in usdt, hold a treasury in usdc. the exchange-rate service in api/services/exchange_rate ties it together.
• player aml hook — a plugin hook on every deposit/withdrawal lets you route through a third-party aml screening service before clearing.

3. e-commerce

cards leave 1.5–3% on the table per sale and saddle you with chargeback disputes. crypto deposits remove both costs at once. HalcoPay plugs into the storefronts you already run.

• global checkout — accept payment from a customer in any country without a banking partner in that country.
• no card fees eating margin — the only fee you pay is the on-chain gas, and you can pass it to the buyer if you want.
• store-aware checkout — HalcoPay has a native Store entity. one merchant, many stores, separate branding, separate wallets, separate webhook urls.
• refunds via real payouts — refunds aren't ledger entries — they're real on-chain payouts back to the buyer's address, recorded as a Refund linked to the original Invoice.

integration: openapi spec at /docs, or use the bundled checkout iframe.

4. marketplace

marketplaces have a special problem: money comes in from one party and goes out to many. HalcoPay handles this natively with batch payouts and per-vendor wallets.

• per-vendor wallets — each seller has their own wallet entity tied to a single store. funds for that seller never co-mingle with another's.
• batch payouts with approval flow — finance prepares the run, an approver signs off, the worker executes — one row in Payout per recipient, all from one transaction batch if the chain supports it.
• settlement automation — a plugin hook on invoice settlement can trigger custom logic — receipts, notifications, accounting entries — the moment funds land.
• multi-store reporting — built-in analytics group by store, by seller, by product.

5. charity

donors give crypto for two reasons: anonymity (when they want it) and provability (when they want the world to know). HalcoPay does both.

• donor anonymity by default — checkout never asks for an email unless you configure it to. the donor is just an address on a chain.
• transparent on-chain reporting — every donation address is public. you can publish your treasury wallet address and let donors verify their gift landed.
• recurring donations via tokens — for monthly giving, generate one-time addresses per donor cycle, or use a smart-contract subscription plugin.
• tax-receipt plugin slot — install a plugin to email a tax-deductible receipt automatically when a donation settles (if your jurisdiction requires it).

your vertical isn't here?

the engine is general-purpose: any business that wants to accept a crypto payment can use it. if your industry has unusual constraints (regulatory, compliance, settlement timing), tell us — adapting the configuration is usually a sprint, not a rewrite.