Why Card Numbers Never Touch Our Servers
Card numbers are among the most sensitive pieces of information a website can handle. Storing them, or even letting them pass through your own servers, brings strict security obligations, regular assessments and real risk if anything goes wrong. A single breach can hurt every customer who ever paid.
Our approach is simple: card numbers never touch our servers. Not in a database, not in a log, not in memory on the way somewhere else. Here is how that works and why we chose it.
Embedded fields hosted by the processor
When someone pays on one of our checkout pages, the card number, expiry date and security code are typed into fields that look like part of our page but are actually hosted by the payment processor. Those fields are isolated from the rest of the page. Our code cannot read what is typed into them, and neither can any other script on the page.
When the customer submits, the card details go directly from their browser to the processor. The processor returns a reference that represents the payment, and only that reference comes back to our server. We work with the reference to complete the order. The card number itself never enters our systems.
On our page, not on someone else's
Some payment setups send customers away to a separate hosted checkout page on another website. That keeps card data off the merchant's servers too, but it breaks the experience: the customer leaves the site, sees a different design and has to find their way back.
We prefer embedded fields on our own page. Customers stay on the site they trust, the checkout matches the organization's branding and card data is still handled entirely by the processor. It is the best of both approaches.
What our servers do handle
Keeping card numbers away from us does not mean our servers do nothing. They:
- Create the payment with the correct amount, currency and description, so the browser cannot change what is being charged
- Pass the processor's reference to the browser so the embedded form can complete the payment
- Receive the processor's verified confirmation that the payment succeeded
- Update the order, membership or subscription and record the payment in the books
The amount is always decided on the server. A customer editing the page in their browser cannot pay one dollar for a hundred-dollar order, because the server set the amount before the form ever loaded.
Saved cards without stored cards
People like saving a card for next time. With embedded processor fields, the saved card lives in the processor's vault, attached to a customer record there. Our platform stores only a reference and harmless display details, such as the card brand and last four digits, where the processor provides them. When we cannot verify those details, we show an honest "card on file" message rather than guessing.
The same rule for every product
This approach applies across our products. Organizations selling through VoVo take payments with embedded fields through their own payment settings. Our own charges go through our shared payment hub, which follows the same rule. Pay by Jag, our payments and bookkeeping product, is built on it as well: customers pay through the processor, and card details never touch Pay by Jag servers.
Why this matters to customers
Customers do not need to understand the architecture to benefit from it. They type their card into a familiar-looking form and pay. Behind the scenes, the most sensitive part of that transaction is handled by a company whose entire business is protecting card data, and our systems simply never have the number to lose. It is one example of a broader rule: failing closed and keeping risk away from places it does not need to be.
Frequently asked questions
Does Jag Journey store my card number?
No. Card details are entered into fields hosted by the payment processor and sent directly to it. Our servers only receive a reference to the payment.
Is paying on the website as safe as a hosted checkout page?
With processor-hosted embedded fields, card data is handled by the processor in both cases. Embedded fields simply keep you on the same website while you pay.
Can someone change the price in their browser?
No. The amount is set on the server when the payment is created, so editing the page cannot change what is charged.
Related Posts
Every AI Call Is Registered Before It Runs
AI features cost money and touch customer data, so we keep a registry of every one. Here is how a call that is not on the list is refused before anything is spent.
Every Payment Lands in the Books
A payment that never reaches the accounting records creates work and risk later. Here is how our payment flows connect to the books from the very first charge.
Idempotency: Making Sure a Payment Happens Once
Networks retry, people double-click and confirmations arrive twice. Here is how idempotency keeps every payment, credit and renewal from happening more than once.
Why Our Website Importers Never Hotlink Your Files
When a website moves to our platform, every image, font and file comes with it. Here is why we never leave a page depending on the old host, and how we prove it.
Audit Trails: Recording Who Changed What
When something changes unexpectedly, the first question is who changed it and when. Here is how audit trails answer that question without becoming a privacy problem.
Comments (0)
No comments yet. Be the first to share your thoughts!