Hosted Payment Fields for California SaaS Companies

Hosted fields for California SaaS companies solve a problem every product team eventually hits: you want a checkout that looks like your app, not a redirect to a processor's page, but you do not want your servers anywhere near a card number. Hosted payment fields are the answer that satisfies both. The card number, expiry and CVV inputs are rendered by the processor inside small iframes positioned within your own form, styled to match, so the customer sees one seamless page and your infrastructure never receives the raw card data. For a company in San Francisco, San Jose, Irvine or San Diego selling seats and usage plans, that is the difference between a self-assessment questionnaire your engineers can finish in an afternoon and a PCI program that needs its own headcount.

What hosted fields actually do

Your page loads a small script from the processor. That script injects iframes for each sensitive input. The customer types into those iframes, which are served from the processor's domain, so the card data is transmitted directly from the customer's browser to the processor. The processor returns a token to your page, and your backend uses the token to create the charge or store the card for future billing. Your code sees the token, the last four digits, the brand and the expiry, but never the full number. Compare that to a redirect-based hosted page, where the customer leaves your site entirely, and to a fully custom form, where your servers receive and must protect the PAN. Flux's hosted fields product is built for this middle path.

PCI scope, stated plainly

PCI DSS assigns merchants to questionnaire types based on how card data flows. If your servers touch card numbers, you are in the deepest end (SAQ D), with hundreds of requirements and often a qualified assessor. If you redirect entirely to a processor page, you are in the shallowest end (SAQ A). Hosted fields, properly implemented, generally qualify for SAQ A as well, though some acquirers place iframe implementations in SAQ A-EP depending on how much of the page you control; ask your processor and your assessor which applies. Either way, you are far from SAQ D. The PCI compliance page describes how the questionnaire and scanning obligations work. Keep in mind that PCI scope is also an underwriting input: a SaaS company that stores PANs in its own database is a materially bigger risk to an acquirer than one that does not.

Why SaaS in particular needs tokens

A subscription business charges the same card repeatedly, upgrades and downgrades plans mid-cycle, retries failed payments, and eventually needs a new card when the old one expires. All of that requires storing something. With tokenization, the stored thing is a token that only works with your processor, useless if stolen. Network account updater services can refresh expired cards behind the token without the customer re-entering anything. Combine tokens with recurring billing and dunning logic, and the whole billing lifecycle runs without your engineers building a card vault.

California law at the checkout step

• Automatic Renewal Law: renewal terms (price, frequency, how to cancel) must be displayed clearly and conspicuously before the customer commits, the customer must affirmatively consent, an acknowledgment must be sent after, and cancellation must be at least as easy as signup, including online cancellation for online signups. Free trials that convert to paid need their own disclosures and a notice before conversion. Design the checkout so the consent checkbox sits next to the hosted fields, and log it.
• SB 478: the advertised price must include mandatory fees. A "$49/mo plus a platform fee" presentation is a problem. Show the all-in number.
• CCPA/CPRA: if you meet the thresholds, customer billing data is personal information subject to access, deletion and opt-out rights. Hosted fields reduce what you hold, which reduces what you have to disclose and delete.

These rules have been enforced actively against subscription companies. Confirm your implementation with counsel; the payment form is where most of the required disclosures live.

Implementation notes from real deployments

1. Style the iframes to match your inputs, including focus states and error messages, so the field boundaries are invisible to the customer.
2. Handle validation events from the fields (invalid number, expired card) in your own UI rather than waiting for a server error.
3. Add 3-D Secure for higher-value plans; it shifts fraud liability and reduces chargebacks on annual prepay.
4. Collect billing zip for AVS; it lowers interchange on some card types and helps with disputes.
5. Do not log the token in analytics or session-replay tools alongside customer identity in ways that would recreate a card vault by accident.

Chargebacks and the subscription pattern

SaaS disputes are mostly "I forgot I was subscribed" and "I could not cancel." Both are prevented by the Automatic Renewal Law compliance you already have to do: reminders before renewal, one-click cancellation, and a descriptor with your product name. Keep the ratio far below the 0.9%-1% network thresholds. Enterprise customers paying annual invoices should be offered ACH, which settles in 1-3 business days at a flat fee and has no chargeback mechanism at all; cards settle in 1-2 business days.

Hosted fields let a California SaaS company own its checkout experience while owning almost none of the risk that comes with card data. Build the consent and disclosure logic around them once, and the state's subscription and privacy rules become part of the form rather than a separate legal project.