Capture remains with your provider
The payment surface uses the SDK and certification path your institution has already assessed.
Card data stays outside the box.
Payment capture is delegated to the assessed SDK your institution supplies. No card number, PIN, CVV, or cryptogram crosses a Box library boundary.
A smaller boundary
Protect the transaction by deciding what Box never receives.
Box records the order, the provider reference, and the result needed to operate the sale. The sensitive payment credential remains with the payment implementation already governed by your institution.
Gateway credentials stay outside the shell
Payments bind through a port. Box modules resolve an implementation without reading its secrets.
Operational context stays useful
Orders, refunds, voids, staff actions, and provider references remain connected for review.
Follow one payment
A clear path with a visible boundary.
Move through the transaction to see which system handles each part and what Box retains.
Your assessed SDK
The credential is captured outside Box.
The customer presents a card or wallet directly to the payment implementation selected by the institution.
Your payment adapter
The provider handles authorization.
The payment port binds to an adapter the institution supplies. Provider credentials remain inside that implementation.
Your commerce record
Box keeps the result, not the credential.
The order stores the provider reference and payment state needed for refunds, reconciliation, and support.
Beyond capture
Controls that follow the payment into operations.
01
Devices prove what they are
Tills enrol with a platform integrity token and hardware backed keys, so a device in the field is one the institution put there.
02
Actions follow staff roles
Merchants give each person the routes their work requires. Refunds, voids, and edits remain tied to the person who performed them.
03
Records remain reviewable
The payment stays attached to its order, channel, staff action, and provider reference instead of becoming an isolated total.
04
Changes happen on your schedule
Nothing changes on a running deployment until its operator runs the upgrade, making review possible before a release is live.
Shared responsibility
Know exactly where responsibility sits.
Your institution operates
The engine, console, database, payment implementation, and merchant access.
They run inside the network, region, monitoring, retention, and identity controls your institution already governs.
Box operates centrally
Licensing, package delivery, domain resolution, and the public website render.
These systems do not hold merchant records. The render resolves a host and fetches from the correct deployment for that request.
For security reviewers
Bring the hard questions early.
We provide component boundaries, package provenance, deployment responsibilities, and the decisions worth reviewing before a pilot. We do not claim certifications that cannot be attached to a report.
Payment security questions.
Does Box handle card data?
No. Payment capture is delegated to the institution supplied SDK. No card number, PIN, CVV, or cryptogram crosses the Box library boundary.
Where do payment credentials live?
Inside the payment implementation the institution supplies. The Box shell binds to that implementation through a port and does not read its gateway credentials.
Does Box claim a PCI certification?
No certification claim is made here. The transaction is governed by the assessed payment SDK and operating environment selected by the institution.
Can one payment provider be replaced?
Yes. Payment capabilities depend on a contract rather than one provider. A new adapter can replace the implementation without changing the order model.
Review Box
Start with the boundary, not the brochure.
Bring your security, payments, and platform teams into the first conversation.
Contact sales