How hosted card fields keep card details off our servers

A card number is valuable because it can be reused. Any page that asks you to type it into the website's own form is asking to hold that value, even if only for a moment. Hosted fields are the opposite design: the box you type in is served by the payment processor, and the website receives a reference instead of the number.

Northline is built that way for the day card payments are open. They are not open now. The public form is a waitlist email. There is no card field on the page, and the payment routes refuse a body that contains a card number or a security code. This article describes the intended design so you can recognize it, not so you can pay today.

What you would type, and where

When charging is enabled, the review step shows a total the server already stored. The card number, expiry, and security code are collected inside the processor's element. That element loads from the processor's domain. Our server never sees those three values. We can receive a brand and the last four digits after the processor confirms a payment, because those are not enough to charge the card again.

We do not add a second, hidden form that posts the raw card "just in case." A switch that can turn such a form on is the pattern this site is written to avoid. If you ever see a card form that is ordinary inputs on northline's own page, stop and contact us. That is not the design.

What the server does store

For a real order the server stores the credit, the fee, the total, a promo if any, a masked phone number, an encrypted full number so a partner can be asked to post the credit, an encrypted receipt email, and the processor's payment reference. Logs are written to drop fields whose names look like contact details or card data.

The order reference is random. Lookup needs that reference and a second factor. The receipt link is signed. It is not a sequential number you can increment.

What we refuse

A request that includes a card number, a security code, or an expiry is rejected. The total in the request is ignored. The amount charged, when charging exists, is the total computed when the order was created. A promo is accepted only if the server's list says it is valid, and it cannot push the fee under one dollar.

Why payments are off

Posting a credit means holding customer funds and handing them to a partner who can reach the provider. That step needs a license or an agency arrangement. Until that exists, turning on card charges would take money for a credit we cannot complete. The waitlist is the public path instead. Joining it does not authorize a future charge. If payments open, you would still see a total and choose to pay. Nothing on the waitlist stores a card.

What you can check yourself

• The waitlist form asks for an email, not a card.
• The Fees page shows the pricing function's results.
• The refunds page says a captured payment is refunded when a credit is not posted.
• The privacy page lists what would be stored if an order exists.
• Support asks for an order reference, not a security code.

None of those checks makes a payment instant, and none of them approves a card. They tell you where data is supposed to go. If a future checkout does not match this description, do not type a card. A matching description is still not approval. The processor can decline a card, and a partner can still fail to post a credit. The refund rule covers the second case when a charge was captured. It does not cover a card that was never charged.

What a careful payer can observe. You do not need the page source to notice the design. The waitlist asks for an email. It does not ask for a card number, an expiry, or a security code. The pricing examples on the Fees page do not ask for them either. The contact form tells you not to include them. If a future payment step appears, the card boxes should be the processor's, and the total should already be on the page from the server. You should be able to leave without typing a card. A page that blocks the back button, or that shows an error and a phone number after you submit a full card to the site itself, is not this design. Close it. Hosted fields are a boundary, not a charm. They reduce what we can store. They do not force a provider to accept a credit, and they do not make a refund instant. The refunds page still governs a captured charge when the credit is not posted. Read that page before you need it, the same way you read the fee before you compare totals.

Questions