◆ Security at Batchly

No badge wall.
Claims with receipts.

You're deciding whether to trust a piece of software with your register and your merchant account. Marketing pages usually answer that with a row of logos. This page does it differently: every security claim below is paired with the artifact behind it — a test that runs, a design that makes the bad outcome impossible, or a process that actually happened.

What you won't find here

A SOC 2 badge. We don't hold that certification, so we don't show one. We'd rather show you the architecture.

What you won't find here

A "PCI certified" claim. Instead: card data never reaches our servers at all — which is what keeps that conversation short.

What you will find

Seven specific claims, each with its artifact. Show this page to your bookkeeper or your IT friend — it's written for them too.

Where card data lives

Card numbers never
touch Batchly's servers.

This is the most important fact on the page, so it comes first. When a customer pays at your counter, the card is read by the payment terminal and travels straight to the payment gateway. Batchly is never in that path — it can't leak, log, or mishandle a card number it never receives.

  • Terminal → gateway, directly
    Card-present payments go from the terminal to the NMI payment gateway. Batchly's servers are not a stop on the route.
  • What Batchly actually sees
    An amount and a transaction ID. That's the whole list — enough to run your reports, nothing a card thief wants.
  • The artifact: it's the architecture
    This isn't a policy we promise to follow — there is no code path that accepts a card number. Compliance by absence.
A card payment · the actual pathBY DESIGN
1
Customer taps or dips at the terminal
The card is read by the payment terminal at your counter.
2
Terminal talks straight to the gateway
Encrypted, terminal → payment gateway. Batchly is not on this line.
3
Batchly receives the result
Just $23.40 and txn_id — an amount and a reference. No card number, ever.
Card data stored by BatchlyNONE — BY ARCHITECTURE
The claims, with their artifacts

Six more claims. Six artifacts.

Each card states what we do, then names the thing that backs it up. If a vendor can't tell you the artifact behind a security claim, the claim is decoration.

Claim · tenant isolation

Your store's data is fenced off at the database itself

Batchly is multi-tenant — many stores, one platform. Every row of every store's data is isolated with Postgres row-level security, enforced by the database engine. One operator can never read another's products, sales, or customers, even if application code has a bug.

The artifact

An automated proof script, not a policy doc. A test signs in as one tenant and attempts to read another tenant's data across the schema; the run passes only when every attempt comes back empty. Isolation is something we execute, not something we assert.

Claim · key custody

Your gateway keys are write-only to the outside world

The credentials that move your money — your payment-gateway keys — are stored in a server-side encrypted vault. They can be written in during setup, and they are used only by locked server-side code when a payment runs.

The artifact

No read path to the browser. There is no endpoint that returns a stored key to any client, dashboard, or API response. A compromised laptop at your shop — or ours — can't exfiltrate what nothing will hand over.

Claim · monitoring

A security watchdog is on duty around the clock

An automated watchdog monitors the platform 24/7 — while you're closed, while we're asleep — watching for anomalies and misbehavior rather than waiting for a customer to report a problem.

The artifact

It's automated, so it never gets bored. The watchdog is running software, not a calendar reminder — coverage doesn't depend on a human remembering to check.

Claim · audit trail

The record of what happened can't be quietly rewritten

Voids, refunds, price changes, overrides — the actions that matter in a store with cash and cards — are written to a tamper-evident audit trail. If a record is altered, the alteration is detectable.

The artifact

Tamper-evident by construction. The trail is built so edits leave evidence — useful when you're reconciling a drawer, and essential when you're settling a dispute with an employee or a processor.

Claim · roles

Each person gets the keys their job needs — and no more

Per-user roles mean the weekend cashier can sell without being able to issue refunds, change prices, or export your customer list. Owner, manager, cashier — each is a different set of permissions.

The artifact

Enforced in the product, per user. Roles are checked on the action, not just hidden in the menu — an account without the permission can't perform the operation, whatever it clicks.

Claim · live/test separation

Experiments can't contaminate your real books

Batchly has a full test mode: live data and test data are kept separate, so trying a workflow, training a new hire, or testing an integration never creates a fake sale in your real reporting or moves real money.

The artifact

Separation is structural, not a label. Test transactions live apart from live ones — the same separation our own developers and API users rely on every day. See the developer docs →

Audits, fixes & the boring fundamentals

We attack our own platform. Then we fix what we find.

Security isn't a launch-day state, it's a habit. Batchly runs recurring security audits and ships the fixes — and keeps the unglamorous fundamentals in place underneath.

  • Recurring multi-agent security audits (2026). Multiple independent automated reviewers sweep the codebase for vulnerabilities — repeatedly, not once.
  • Findings become shipped fixes. The point of an audit is the patch. Issues found in our audits have been fixed and deployed — that loop is the artifact.
  • Plain-English terms, published. The legal agreement you sign is public before you sign it — no fine-print surprises. Read the terms →
HTTPS + HSTSEvery connection encrypted in transit, with browsers instructed to never accept an unencrypted one.
STRICT CSPA strict Content-Security-Policy limits what the pages themselves are allowed to load and run.
ENCRYPTED VAULTGateway secrets encrypted at rest, server-side, write-only from the outside.
DATABASE-LEVEL RLSTenant fences enforced by the Postgres engine — below the application, where bugs can't reach.
Responsible disclosure

Found something? Tell us directly.

If you believe you've found a security issue in Batchly, we want to hear about it from you first — and we'll take it seriously. Email us with enough detail to reproduce what you saw, and a human on our team will read it.

✉ hello@batchly.shop · subject line "Security" Please give us a reasonable window to investigate and fix before sharing details publicly. We won't pursue anyone acting in good faith to report a genuine issue.
Still deciding?

Ask us the hard questions yourself.

Bring your bookkeeper or your IT friend to the call — we'll walk through any claim on this page in as much depth as you want, and give you a straight answer on pricing while we're at it.

By calling or texting, you consent to receive messages from Batchly (AgentMachine LLC). Msg & data rates may apply; msg frequency varies. Reply STOP to opt out, HELP for help. SMS Terms · Privacy