Know what’s on your site before a plaintiff’s firm does
A free privacy audit shows which cookies, pixels and trackers are running — and which ones commonly appear in privacy claims.
A cashier asks for a ZIP code. A payment screen asks for a phone number. An electronic receipt requires an email address, which then appears in the retailer’s marketing database. These familiar requests deserve their own privacy review. In California, the Song-Beverly Credit Card Act can restrict the collection of personal identification information in connection with accepting a credit card, even when the dispute involves no security breach and no alleged interception by a third-party tracker.
The law belongs in Captain Compliance’s privacy lawsuit series because it addresses an earlier stage of the data lifecycle: how a business obtains information from a customer. Our CIPA coverage, ECPA analysis and articles on state wiretap laws examine acquisition and transmission of communications. Song-Beverly asks a different question: did the merchant improperly request and record information in the credit-card transaction?
For retailers, that distinction changes the scope of the assessment. A privacy policy and a consent banner may address disclosures and website technologies while leaving a required checkout field untouched. A well-protected customer database can still contain information collected through a transaction flow that needs revision. Review the checkout itself, then follow the information into the systems that use it.
The statute concerns credit-card transactions and personal information
The relevant privacy provision is California Civil Code Section 1747.08, within the Song-Beverly Credit Card Act of 1971. It addresses requests or requirements for personal identification information in connection with credit-card acceptance, including information the merchant records electronically or otherwise. It also addresses credit-card forms with designated spaces for that information. The statutory definition excludes information set forth on the credit card and expressly includes addresses and telephone numbers.
The provision contains transaction-specific exceptions, including deposits, cash advances, certain contractual or legal obligations and information required for a special purpose related to the individual transaction. Its civil penalties are capped at $250 for the first violation and $1,000 for each subsequent violation. The statute also includes a bona fide error defense requiring an unintentional violation despite maintained procedures reasonably adopted to avoid the error.
This is the Credit Card Act, not the similarly named Song-Beverly Consumer Warranty Act commonly discussed in vehicle and product-warranty disputes. Nor is Section 1747.08 a general ban on every request for customer information. The payment type, timing, collection circumstances and applicable exception matter.
A useful assessment begins with a specific field and a specific transaction. Identify whether the customer paid by credit card, what the interface or cashier communicated, who recorded the information and why it was needed. Describing the entire checkout as “consented” or “necessary” is less informative than explaining each contested field.
Pineda v. Williams-Sonoma: a ZIP code can be protected information
In Pineda v. Williams-Sonoma Stores, Inc., 51 Cal.4th 524 (2011), the California Supreme Court held that a ZIP code constitutes personal identification information under Section 1747.08. Jessica Pineda alleged that a cashier requested her ZIP code while she paid by credit card, that she believed it was required and that the retailer recorded it. The complaint further alleged that software combined her name and ZIP code to locate her home address.
The court reversed the dismissal of the statutory claim and remanded. Because it reviewed a demurrer, it accepted the pleaded facts for that purpose; the decision was not a trial finding that every alleged downstream use occurred. Its holding nevertheless rejected the argument that a ZIP code falls outside the statute merely because it identifies an area rather than one individual.
The case gives privacy teams a concrete reason to examine small fields. In an illustrative modern flow, a retailer could connect an identifier with transaction history or an existing customer record. Whether that happens in a particular deployment requires evidence. The review should consider both the field collected and the records with which the business combines it.
Tokenizing a payment does not answer the separate question of what customer information entered the merchant’s system. Payment security and collection restrictions should be reviewed together, with their different purposes kept clear. A secure system can preserve unnecessary identifiers very effectively.
Florez: collecting information just before payment is not a reliable workaround
Florez v. Linens ’N Things, Inc., 108 Cal.App.4th 447 (2003), concerned allegations that a cashier requested and recorded a telephone number before the customer presented her credit card. The court reversed dismissal, rejecting the proposition that asking before the payment method became known necessarily avoided the statute. It examined the request from the customer’s standpoint, including whether the customer could perceive it as a condition of completing the credit-card transaction.
The retailer’s undisclosed intention to use the information for marketing did not resolve that perception. The decision is useful when reviewing a checkout that collects identifiers at the beginning of the flow and only later asks for payment. Moving a field one screen earlier does not, by itself, establish a separate voluntary interaction.
Consider a hypothetical point-of-sale terminal that asks for a phone number before displaying payment options. Staff can bypass the screen, but customers do not see that option. The relevant evidence includes the screen, instructions and actual checkout sequence. An internal database flag calling the field “optional” may describe the software configuration without describing the customer’s experience.
For product teams, the test should include the decline path. Can a customer proceed without the information? Does the interface explain that choice? Do staff instructions contradict the displayed option? These are practical questions for assessing the circumstances, rather than a claim that a particular label automatically satisfies the law.
Email receipts and marketing: Capp v. Nordstrom
In Capp v. Nordstrom, Inc., No. 2:13-cv-660 (E.D. Cal. Oct. 21, 2013), the plaintiff alleged that a cashier requested his email address for an electronic receipt during a credit-card purchase and that the address was later used for unsolicited promotional messages. The federal district court treated an email address as personal identification information and denied the motion to dismiss. It also rejected the asserted CAN-SPAM preemption defense.
The ruling concerned a pleaded transaction and should not be expanded into a rule that every digital receipt is unlawful. It does show why explaining a request as “for your receipt” does not end the analysis, particularly where the customer allegedly understood the address to be required and subsequent marketing use was alleged.
A receipt service, a customer-account system and a marketing platform should have distinguishable purposes in the data map. If an email address enters a receipt workflow, identify whether an integration also creates a marketing contact, subscribes the customer or exports the address elsewhere. The software’s default behavior may differ from what the cashier or interface tells the customer.
The recommendation is to keep transaction communications and promotional enrollment separate. Document the route by which an address was acquired and the permission relied on for additional uses. Compliance with rules governing an email’s content or unsubscribe mechanism does not independently establish that the address was obtained properly.
Harrold and the later Williams-Sonoma cases: context and completion matter
In Harrold v. Levi Strauss & Co., 236 Cal.App.4th 1259 (2015), the Court of Appeal affirmed denial of class certification. The evidence supported a policy of requesting email-program information after the credit-card purchase had concluded, with the receipt and merchandise delivered. The court rejected an interpretation extending the collection prohibition indefinitely beyond the completed transaction.
That reasoning permits a meaningful distinction between payment and a subsequent invitation to join a program. It does not make the precise instant a card is authorized a universal safe harbor. For a digital design, assess whether the purchase actually can conclude without the information and whether the later invitation appears clearly separate from completing it.
In Williams-Sonoma Song-Beverly Act Cases, A154692 (Cal. Ct. App. Sept. 30, 2019), the court affirmed class decertification and applied the reasonable-customer standard from Harrold. The collection circumstances varied, making individual transaction questions relevant to class treatment. The decision concerned class certification; it did not approve every request Williams-Sonoma had made.
Together, these opinions support preserving the customer-facing sequence. For an in-store review, retain the checkout script and training materials alongside the software settings. For an online review, preserve screenshots and validation behavior by version. An asserted companywide policy is more useful when there is evidence that the deployed flow implements it.
Online purchases require careful treatment of Apple and Ambers
In Apple Inc. v. Superior Court, 56 Cal.4th 128 (2013), involving David Krescent’s purchases of electronic downloads, the California Supreme Court held that Section 1747.08 does not apply to online purchases in which the product is downloaded electronically. The court considered the statutory scheme and fraud-prevention concerns in transactions lacking the physical verification procedures available to stores.
The holding should retain its stated scope. It concerned electronically downloaded products. It was not a general declaration that all information collected on the internet may be required for every credit-card purchase. A physical-goods retailer should identify the authority relevant to its transaction rather than relying on a shortened summary of the Apple case.
The Court of Appeal extended the reasoning to the circumstances of Ambers v. Beverages & More, Inc., 236 Cal.App.4th 93 (2015). The plaintiff purchased merchandise online by credit card and retrieved it at a store. The court held the provision did not apply to that transaction and affirmed judgment for BevMo. Its conclusion depended on an online purchase completed before pickup, as alleged in the original complaint.
The cases make transaction classification a substantive part of the review. A digital download, a purchase paid online for store pickup and a reservation paid at the counter do not necessarily present the same facts. Shipped merchandise raises its own questions about the governing decisions and any information needed to fulfill the order. Treating all these flows as “ecommerce” loses distinctions that counsel needs.
The Anova settlement connects checkout privacy with pixel controls
The settlement materials in Margaret McClure v. Anova Applied Electronics, Inc., No. CGC-24-615351, San Francisco Superior Court, describe allegations that customers had to provide personal identification information during website or mobile-app credit-card purchases. Anova agreed to a $500,000 settlement fund. The published materials state that Anova denies the allegations and that the settlement is not an admission of wrongdoing.
The business-practice commitments describe checkout disclosures distinguishing transaction and fraud-related purposes from marketing, separate marketing choices with unchecked defaults, and restrictions on marketing use of personal information and IP addresses without opt-in. They also describe an optional consent banner and gating marketing and analytics pixels behind explicit consent, with the default off. The commitments run for two years from preliminary approval and concern website users geolocated in California.
These are negotiated case-specific commitments, rather than a judicial holding that Section 1747.08 requires every merchant to deploy that exact design. They offer a useful operational example: the checkout’s collection purposes, marketing enrollment and third-party tracking were addressed together. The payment flow and the advertising stack can share information even when different teams manage them.
For a hypothetical merchant, revising a checkbox while leaving the same address automatically subscribed through a server integration would create a mismatch between the displayed choice and the workflow. Blocking a browser pixel while exporting the record through a marketing API would leave another route to examine. The assessment needs both the interface and the downstream configuration.
Shipping, fraud prevention and identification need distinct justifications
Section 1747.08’s exceptions include information required for a special purpose related to the individual transaction, such as shipping, delivery, servicing, installation or special orders. The examples do not eliminate the need to identify why the particular field was required. Pineda also recognizes the statute’s exceptions for certain contractual and legal obligations.
A useful field review distinguishes an address needed to deliver an order from additional information requested for audience enrichment. The business should document the function of each field, rather than assign the entire customer record the purpose “fulfillment.” If a phone number is required, identify the actual service that needs it and whether a different method can serve the transaction.
Fraud-prevention arguments also need precision. The statutory text expressly contains a ZIP-code exception for specified automated motor-fuel transactions when used solely to prevent fraud, theft or identity theft. That particular exception should not be described as blanket authorization for all retail ZIP-code requests. Elsewhere, a contractual-obligation argument should identify the relevant obligation rather than rely on the fact that a vendor’s software exposes a field.
In discussing physical identification, Apple explains the statutory distinction between checking identification and recording information from it. A checkout review should consequently treat inspection, transcription and retention as different operations. Replacing a cashier’s visual check with a scanner that saves the document may change the collection facts materially.
These distinctions do not mean fraud tools or fulfillment systems must be removed. They mean that a business should be able to explain what it collects for the transaction and how it keeps that workflow separate from unrelated uses. A label in a privacy policy is less informative than the actual routing and settings.
Credit cards, debit cards and returns should not be collapsed into one category
In Johnson v. Ashley Furniture Industries, Inc., No. 3:13-cv-2445 (S.D. Cal. Nov. 4, 2014), the district court dismissed Section 1747.08 claims to the extent they depended on debit-card transactions. It distinguished cards used to obtain goods or services on credit from cards drawing on bank-account funds. The opinion cautions against assuming that every payment routed through a familiar card network falls within the provision in the same way.
In Absher v. AutoZone, Inc., 164 Cal.App.4th 332 (2008), the Court of Appeal held that the purchase-related restrictions did not apply to the return transaction before it, which reversed the original credit-card purchase. A business should distinguish that holding from any assertion that returns information may be used without limits under every other privacy rule.
Preserve transaction type in the assessment record. Purchases, refunds, deposits and exchanges can follow different interface paths and retention policies. A report that counts every interaction identically can overstate or understate the actual exposure.
How Song-Beverly differs from the other laws in this series
| Framework | Question for the privacy review | Evidence to examine |
|---|---|---|
| Song-Beverly Credit Card Act | Was personal identification information improperly requested and recorded in the credit-card transaction, considering its circumstances and exceptions? | Payment type, checkout sequence, required fields, staff requests and collection purpose. |
| CIPA and federal ECPA tracking claims | Did a technology acquire communications in a way prohibited by the particular provision, and does consent or another defense apply? | Network requests, capture timing, payloads, recipients and the asserted authorization. |
| WESCA, Illinois and Ohio communications laws | How do the relevant state’s participation, consent and other requirements apply to the acquisition or use alleged? | The identified communication and facts supporting each statutory element or exception. |
| CCPA / CPRA | For a covered business, do collection disclosures, consumer-rights workflows and applicable sale or sharing controls match processing? | Notices, data inventories, purposes, recipient arrangements and implemented choices. |
The California Attorney General’s CCPA guidance explains that a notice at collection identifies the categories collected and their purposes and must be available at or before collection. That is a disclosure obligation within a separate framework. Displaying the notice does not independently resolve a restriction on how information is requested in a credit-card transaction.
Similarly, a valid choice about marketing pixels does not necessarily answer whether a merchant’s own required field was appropriate. A Song-Beverly claim does not need to reproduce the theory in a CIPA demand letter. Each count should be examined against its own trigger, defenses and remedies.
For Captain Compliance’s series, the connecting issue is control over the data flow. Review what the business asks for, what it captures, where it sends the information and which purpose each step serves. The legal assessment then applies the appropriate statute to those facts, rather than treating all privacy cases as interchangeable wiretap claims.
Review checkout behavior before revising the privacy policy
Start with a field inventory for in-store terminals, desktop and mobile checkouts, apps and pickup flows. Record which fields block completion, which are optional and which appear only under certain conditions. Include third-party checkout extensions and accelerated payment options. A platform’s default configuration is a starting point for inspection, not evidence that the merchant has considered its California collection practices.
Test each field’s decline path and record what the customer sees. Check whether a missing phone number prevents progression even though the page labels it optional. For staff-assisted purchases, compare training instructions with the terminal sequence. If employees are expected to obtain a high percentage of phone numbers or email addresses, assess whether those instructions create pressure inconsistent with the stated choice.
Separate post-purchase enrollment from finishing the purchase. Where the organization relies on a completed transaction to distinguish a later invitation, preserve evidence that payment and delivery of the relevant purchase confirmation can occur without enrollment. Avoid describing a recommendation as a guaranteed legal safe harbor: the actual circumstances remain part of the analysis.
Next, map the integrations. Determine whether receipt information creates a customer profile, enters a marketing list or is sent to an advertising audience. Check server-side exports as well as browser tags. One purpose field on a customer record may be insufficient if several systems treat its presence as permission for different activities.
Preserve meaningful evidence of optional choices, including interface version, the wording presented and the resulting system state. A stored “subscribed” value is weaker evidence if an integration can set it automatically. An opt-out control that updates the storefront but leaves another marketing system unchanged needs remediation and retesting.
When a complaint or demand arrives, preserve the historical flow before changing it. Retain relevant screenshots, validation rules, checkout releases, cashier instructions and integration settings. Identify the payment type and claimed collection event. Then distinguish what the evidence establishes from allegations about later enrichment or disclosure.
Where Captain Compliance can support the review
Captain Compliance’s ecommerce privacy tools support consent experiences, configured blocking of tracking technologies, privacy notices, visitor-choice records and ongoing website monitoring. Those controls can help a retailer address the tracking and marketing side of a checkout review and maintain evidence as integrations change.
Song-Beverly also requires attention to checkout fields and staff practices. A cookie scanner cannot determine whether a cashier implied that a phone number was mandatory, and a banner does not automatically make a required merchant field appropriate. The practical work should connect the consent system with the ecommerce team’s field review and counsel’s assessment of the relevant transactions.
A retailer should be able to explain why each checkout field exists and demonstrate what happens when the customer declines an optional use. It should also be able to identify where transaction information goes after collection. Book a demo to review how Captain Compliance can support the consent, tracking and evidence controls around that workflow.
Put this into practice
Turn privacy guidance into working controls.
Captain Compliance helps teams discover tracking technologies, enforce consent, manage privacy requests and document the evidence behind every decision.