Bill your clients for the software you build, licenses and services, with hosted payment links or an HMAC-signed API. Run gift cards and prepaid credit for your tenants at the same time. Every charge lands in a double-entry ledger: the single source of truth for your reconciliation.
Total volume
$128,540.00
+12.4%
Transactions
3,412
+4.1%
Success rate
99.2%
+0.3%
Volume over time
Last 30 days
Recent transactions
Northbeam Labs
License · card
+$2,400.00
Succeeded
CloudScale Inc
Payment link
+$860.00
Succeeded
Pioneer Co
Gift card
+$150.00
Succeeded
StackOne
API charge
+$1,290.00
Succeeded
Trusted by innovative companies
Issue, sell, and reconcile from one portal. No stitching together half a dozen loose tools.
Hosted payment links or a virtual terminal. Charge with a shared link or by hand, same risk checks either way.
Bill licenses, subscriptions, and services from your own backend through an HMAC-signed API.
Issue gift cards and closed-loop balance your customers load once and spend inside your system.
Postgres Row-Level Security per tenant, signed requests, TOTP two-factor, and PCI tokenization.
If your business needs someone to load balance with a card and spend it later inside your own system, this is for you.
Sell prepaid credit in-store or online: the customer loads balance once and spends it again without repeating the full checkout.
Issue balance for on-site consumption, bars, food stands, merch, and close and reconcile it all from the same ledger.
Turn rewards or memberships into redeemable balance, with full traceability of every load and every spend.
Each tenant runs its own balance and reconciliation, isolated by RLS, under one platform you operate.
Security and trust
We never process or store card data: tokenization runs through our PCI-certified processor. Everything else, tenant isolation, request signing, access control, is an architecture decision, not a marketing promise.
The ledger is your audit trail too
The double-entry ledger is not just for reconciliation: it is a record where every balance movement is backed by debits and credits that balance. If something does not add up, it shows, it does not hide behind a separately computed balance.
Every business table carries a tenant_id, and it is Postgres, not an app filter, that decides which row each tenant sees. The runtime connection has no permission to bypass that policy.
Every API call carries HMAC-SHA256 over timestamp and body, with an anti-replay window. A leaked token without the matching signature is useless.
Opt-in per portal user, with any standard authenticator app. Whoever handles balances can require it without relying on SMS.
Short access tokens and refresh that rotates on every use. A stolen, reused refresh token is detected and kills the session.
For developers
Every charge request carries your api_key and an HMAC-SHA256 signature over the timestamp and body, with an anti-replay window. You choose the idempotency key; we process the signed webhook back to you.
Read the API docs# HMAC-SHA256 sobre timestamp.body curl https://api.dcgeeks.net/v1/charges \ -H "Authorization: Bearer $API_KEY" \ -H "X-Signature: $SIG" \ -d '{"amount":240000,"currency":"USD"}'
No. The balance is closed-loop: it is loaded with a card and spent inside the platform (gift cards, redemptions, terminal). It is not a way to move money out of the system.
There is no self-serve signup. The platform creates your tenant access and hands you the credentials; from there you can invite your team.
No. Card numbers and CVV are tokenized by our PCI-certified payment processor; we never touch or persist them.
It is structurally hard: isolation is enforced by Postgres Row-Level Security on every table, not an app filter a bug can bypass.
Every balance movement posts a double-entry record where debits always equal credits. You can audit the ledger, not just trust an on-screen balance.
Yes. Every request is signed with HMAC-SHA256 and you receive the final state via signed webhook; no manual polling needed.