In our day-to-day work at Techtide Solutions, we treat CVV2 as a tiny field with outsized consequences. It’s small enough to fit in a checkout modal, yet consequential enough to influence authorization decisions, fraud models, and customer trust. The CVV2 security code is best understood as a “possession signal”: a brief code printed on the card that is intended to be hard to guess and inconvenient to obtain without physically holding the card.
What Is CVV2 and What It Verifies in Card-Not-Present Payments
1. CVV2 as a three- or four-digit printed security code on payment cards
From the merchant’s perspective, CVV2 is part of the card-not-present (CNP) toolkit—one more input that can raise confidence when the buyer is not standing in front of a cashier. From the cardholder’s perspective, it’s the reason a stolen card number alone often isn’t enough to complete an online purchase.
Across the broader payments ecosystem, McKinsey describes the industry as generating $2.5 trillion in revenue, and that scale is precisely why even “small” verification steps matter: tiny interface choices, logging practices, and API defaults can ripple into real fraud losses or real customer friction at massive volume.
2. What CVV2 verification helps confirm: card possession and account legitimacy
CVV2 does not “prove identity” in the way people casually assume. Instead, it helps answer a narrower question: “Does the buyer likely have access to the physical card (or a representation of it) right now?” When the code matches, the issuer gains a bit more confidence that the transaction is not coming from someone who merely scraped a card number from a breached database or intercepted it from a merchant receipt.
In risk terms, CVV2 is a guardrail against a specific failure mode: account details that were copied but not accompanied by the physical artifact. That makes it meaningful for basic credential-stuffing-style fraud against payment forms, but far less effective against attacks where the victim is actively tricked into typing everything into a fake page.
Operationally, we also see CVV2 function as a “checkout hygiene” filter. Customers who mistype card numbers often mistype the code too, and issuers can use mismatch patterns (in combination with other signals) to decide whether to approve, decline, or step up authentication.
3. Why CVV2 is requested for online and over-the-phone transactions when in-person checks aren’t possible
Online and phone transactions remove a lot of the natural friction that historically protected card payments. There’s no chip reader handshake in a typical e-commerce checkout, no physical card inspection, no signature comparison, and no human cashier noticing that a buyer is behaving oddly. Because of that, merchants and processors look for lightweight signals that can be collected quickly and validated quickly.
From a standards standpoint, the PCI Security Standards Council explicitly confirms that card verification codes are commonly requested during card-not-present transactions, which aligns with what we observe in production systems: most mature payment flows will request the code at least for first-time purchases, higher-risk carts, or certain geographies.
Practically speaking, CVV2 also helps merchants reduce disputes. If a transaction later becomes a chargeback, having performed CVV2 checking can support the story that the merchant used reasonable verification steps, even though it’s not a silver bullet and does not guarantee liability protection by itself.
Common Names for CVV2 Security Codes Across Card Networks
1. Industry and issuer terminology: CVV2, CSC, CVC, CVC2, CID, CCV, CVVC, and CVD
Payments people love acronyms the way sailors love knots: we use them because the system is complex, and then we suffer because the system is complex. The CVV2 security code is a perfect example. Depending on the card network, issuer, processor, or even the payment gateway’s UI copy, the same underlying concept may be labeled with a different abbreviation.
We’ve watched this create entirely avoidable abandonment. A customer sees “CID” and assumes it’s something unrelated to “CVV.” Another customer sees “CVC” and thinks it must be a bank PIN. Meanwhile, a call-center agent hears “security code” and asks for the wrong digits on an American Express card layout. None of those are “security failures”; they’re language failures.
When we design payment forms, we treat naming as part of security engineering. Clarity reduces mis-entry, and mis-entry reduces noisy declines that look like fraud to an issuer’s risk engine.
2. How card-brand naming differences can affect what a checkout form calls the code
Checkout copy often comes from a blend of sources: the gateway’s hosted-fields widget, the merchant’s design system, and the product team’s own assumptions. If those assumptions are wrong—or simply mismatched with the buyer’s card brand—customers hesitate right where you least want them to: at the point of payment authorization.
In our experience, the safest approach is to avoid over-specific jargon unless the form can detect the brand and change its label and helper image accordingly. If the user has not typed enough digits of the card number for brand identification (or brand detection is disabled for privacy reasons), neutral wording like “Security code” plus a clear inline illustration is usually the least confusing.
Even in that neutral approach, we still prefer to include microcopy that acknowledges the ambiguity: “This code may be called CVV, CVC, or CID.” Language like that lowers support tickets because it tells customers they are not crazy—the industry really does use multiple names.
3. How “card security code” and “card verification value” map to the same basic concept
Different labels emphasize different mental models. “Card security code” makes it sound like a password. “Card verification value” makes it sound like a mathematical checksum. In reality, the working concept for a buyer is simpler: it’s a short printed code that the merchant may request to confirm the buyer has access to the card during a remote transaction.
From a systems lens, what matters is not the label but how the data is handled: whether the value is collected securely, transmitted securely, validated by the issuer, and then discarded according to compliance rules. Names can drift; requirements shouldn’t.
Our internal rule of thumb is blunt: if the UX treats CVV2 as a “password,” users will start reusing it mentally, storing it insecurely, or sharing it casually. If the UX treats it as a “verification step,” users are more likely to handle it as transient input.
Where to Find the CVV2 Security Code on Your Card
1. Visa, Mastercard, Discover, Diners Club, and JCB: three digits on the back signature panel
For most card brands in everyday circulation, the CVV2-style code is located on the back near the signature area. That placement is deliberate: it keeps the code separate from the main account number on the front, and it makes casual shoulder-surfing less likely in some in-person situations.
In consumer support, we’ve found that the phrase “signature panel” is more helpful than “the back of the card” alone, because plenty of modern cards have busy backs (logos, contactless marks, QR codes, issuer text). Pointing users to the signature area narrows the search.
One more practical note: if a buyer reads the code over the phone, background noise and fast speech can turn a routine transaction into a decline. In call-center flows, we prefer “read it slowly, one digit at a time” prompts, because fewer mistakes mean fewer unnecessary issuer retries (and fewer fraud flags triggered by repeated attempts).
2. American Express: four digits printed on the front of the card
American Express tends to trip people up because the code placement differs from the “most cards” pattern. When a checkout form blindly says “look on the back,” Amex customers pause, rotate the card twice, and start guessing—which is exactly the sort of behavior that increases authorization friction.
From a UX standpoint, we like brand-aware helper images for this reason. A tiny inline illustration can remove ambiguity without adding paragraphs of copy. The guiding principle is to reduce time-to-confidence: the faster the user feels certain they found the right code, the less likely they are to abandon the purchase or mistype sensitive data.
In our own QA scripts, we always test Amex flows explicitly. If a payment form is “technically correct” but confusing to a major card segment, it’s not correct in the way that actually matters to revenue and support load.
3. Newer card layouts: CVV2 in a separate panel to reduce accidental overwriting
Card design evolves for boring, practical reasons—like ink smearing, signatures overwriting nearby digits, and wear-and-tear making small print illegible. Some newer layouts separate the code into its own mini-panel, visually isolating it from the signature area.
That design choice affects software, too. When people can’t find the code quickly, they do what humans do: they take photos, they zoom, they copy the digits into notes apps “just for a second.” In other words, poor legibility doesn’t merely cause checkout errors; it can indirectly encourage unsafe storage habits.
Because of that, we consider “help the user find the code fast” to be part of security work, not just a conversion tweak. Good security is often just good ergonomics applied to sensitive workflows.
4. If the code isn’t printed on the card: check the issuer’s mobile app or follow form instructions if the field can be left blank
Occasionally, users run into card products where the code is not easily visible: some virtual-first issuance flows, some controlled corporate programs, and some prepaid experiences can behave differently from the “typical plastic card” assumption. In those moments, users should follow issuer guidance rather than guessing, because guessing invites repeated declines and potential fraud controls.
From the issuer side, there are industry mechanisms to bridge the “no plastic yet” gap. Visa, for example, describes issuer tooling that can request dynamic CVV2 codes in digital issuance contexts, which hints at a broader reality: modern payments increasingly treat “the code” as something that can be mediated by secure issuer channels, not only printed ink.
On the merchant side, some payment forms label the field as optional in edge cases, or they route certain transactions through alternative verification steps. The right behavior is not to force a value at all costs, but to align with your gateway’s and acquirer’s rules and to clearly communicate what the customer should do next.
CVV1 vs CVV2 vs iCVV: Understanding the Different Code Types
1. CVV1 or CVC1: encoded in the magnetic stripe for card-present swipe transactions
When people say “CVV,” they often mean the printed code. Yet the payments world distinguishes between different verification values depending on how the card data is captured. CVV1 (often called CVC1) is typically associated with magnetic-stripe track data and is used in card-present swipe contexts.
In plain terms, CVV1 is part of what makes raw track data dangerous: if an attacker captures it, they may be able to reproduce a swipe-style transaction in environments that still accept magstripe data. That’s one reason the industry moved so aggressively toward chip-based payments in many regions.
From a software integration standpoint, the big takeaway is this: CVV1 is generally not a field you ask the user to type. It’s an artifact of how the payment instrument is read by hardware, not an interactive security step the user knowingly performs.
2. CVV2 or CVC2: printed on the card for card-not-present verification
CVV2 is the one most customers recognize because it’s the one they are asked to type into an online form or say aloud during a phone order. It’s designed for card-not-present verification, where the merchant cannot rely on chip reads or physical inspection.
In our build reviews, we treat CVV2 as a “high-sensitivity input” even though it is short. That means tightening where it can flow, how long it can exist in memory, and which logs it can accidentally hit. The code’s length does not determine its risk; the compliance rules and fraud utility do.
Crucially, because CVV2 is user-entered, it’s also user-exposed. That turns ordinary threats—phishing, screen recording malware, browser extensions—into direct CVV2 capture mechanisms.
3. iCVV and other electronically generated codes for chip and contactless transactions
Chip and contactless transactions shift the security model away from “static printed secrets” and toward “cryptographic conversation.” Instead of proving possession by asking the user to retype a short code, the chip can generate transaction-specific values and cryptograms that are hard to counterfeit at scale.
Even though the term “iCVV” is widely used in industry discussions, the essential business idea is simpler than the acronym: modern cards can carry additional verification values inside the chip ecosystem to reduce the usefulness of copied data. That’s one reason stolen card details often work better online than they do at an EMV chip terminal in markets where chip is well-enforced.
From our viewpoint, this is also why merchants should avoid treating CVV2 as the “main” fraud control. The payments ecosystem already has multiple layers, and the strongest layers often operate without making the user type anything extra.
4. CDCVM in mobile wallets: device-based verification methods like biometrics or passcodes
Mobile wallets introduced a major shift: the buyer can authenticate on their own device in a way that the merchant never sees directly. EMVCo describes this on-device authentication as known as Consumer Device Cardholder Verification Method (CDCVM), and it includes methods such as device passcodes and biometrics.
In practical product terms, CDCVM changes the user experience: the “verification step” becomes a Face ID prompt or fingerprint touch, not a request for a printed code. That’s usually faster and less error-prone, and it reduces the chance the customer will expose sensitive card data to a sketchy website.
At Techtide Solutions, we like CDCVM-backed wallet options not just for convenience, but because they shift risk away from “user typing secrets into forms,” which is a threat model the modern internet punishes relentlessly.
How CVV2 Is Generated and Validated During Authorization
1. Issuer-generated security codes created at card issuance using cryptographic methods
Merchants do not “generate” CVV2; issuers do. At issuance time, the issuer (often through secure card-personalization systems) creates verification values based on the card’s account data and issuer-held secret keys. That secret material is precisely what makes the value hard to derive from the card number alone.
A good way to understand the mechanism without oversharing sensitive implementation detail is to look at modern payment cryptography tooling: AWS describes CVV2 verification as a process that can be validated using a key, the PAN, and the card expiration date, which captures the core concept: CVV2 is not random decoration; it is tied to issuer-controlled cryptographic material.
In real systems, those cryptographic keys are typically protected in dedicated security infrastructure, and they’re treated as high-value assets. If the issuer’s keys are protected, attackers can steal millions of card numbers and still struggle to reliably compute the missing verification data.
2. Why CVV2 is printed and not embossed, and why it’s not encoded on the magnetic stripe
Embossing is designed for mechanical imprinting. Printing is designed for human reading. CVV2 exists for human entry, so it’s printed in a way that is visually distinct from the account number formatting and less likely to be captured by older imprint-based processes.
Meanwhile, encoding CVV2 in the magnetic stripe would defeat much of its purpose. If the code were present in track data, anyone who skimmed the stripe could harvest it in the same pass as the card number. The better design is separation: let swipe data support card-present workflows, and let a printed code support card-not-present checks.
As a system designer, we read this as a broader principle: security controls should avoid collapsing into a single capture channel. When multiple secrets can be harvested in one skim, attackers get leverage; when they have to cross contexts, they lose efficiency.
3. How CVV2 is transmitted in authorization requests for issuer validation during checkout
When a customer types the code, the merchant’s frontend should send it only to the payment processor or gateway—ideally via hosted fields or tokenization patterns that prevent the merchant’s own servers from ever touching it. From there, the gateway formats an authorization request and forwards it through the acquiring side toward the issuer.
The issuer then checks whether the submitted value matches what it expects for that card account. The PCI Security Standards Council describes that these verification codes are validated by the issuer during authorization, which matches the operational reality: the issuer is the ultimate party that can confirm correctness because the issuer controls the reference data and the keys behind it.
In fraud practice, the merchant often receives a response indicator from the processor about whether the CVV2 matched, mismatched, or was not processed. Mature risk engines treat that result as one signal among many, not as a binary truth statement about legitimacy.
4. Why CVV2 does not appear on receipts, statements, or typical transaction records
CVV2 is categorized as sensitive authentication data, and the ecosystem is designed so it does not persist in ordinary transaction artifacts. Cardholder-facing records—receipts, order confirmation emails, invoices—are meant to help reconcile purchases, not to reproduce the credentials needed to initiate new ones.
Compliance expectations reinforce this. PCI SSC explains that audio/voice recordings are not permitted to contain sensitive authentication data after authorization, and that same compliance logic applies broadly: if you shouldn’t retain it, it shouldn’t be casually present in logs, recordings, or customer-service tooling.
From our engineering standpoint, this is where “secure by default” matters. If your systems accidentally log request bodies, if your support tools auto-record calls, or if your analytics SDK captures form fields, CVV2 can leak without anyone intending to do something malicious. Designing to prevent retention is not a compliance checkbox; it’s a data-flow discipline.
Why Merchants Can’t Store CVV2 (PCI DSS) and What That Means for Billing
1. PCI DSS restrictions on storing CVV2 and other sensitive authentication data after authorization
The PCI DSS rule here is intentionally strict: merchants and service providers are not allowed to store CVV2 after authorization. Importantly, this is not a problem you can “solve” with encryption at rest, because the prohibition is about retention itself, not just protection.
In our experience, this is one of the most misunderstood parts of payments compliance among product teams. People assume, “If we encrypt it, we can keep it.” Yet PCI SSC’s guidance is explicit that storing this category of data after authorization is prohibited, even in forms that feel “secure” from a typical web-app perspective.
For engineering teams, the practical translation is architectural: make sure the value never lands in databases, logs, analytics events, error traces, session replays, or call recordings. The safest CVV2 is the one your environment never had to begin with.
2. How “no CVV2 storage” reduces the usefulness of stolen card numbers from breached databases
Attackers love economies of scale. A breach becomes more valuable when it includes everything needed to transact. When a merchant stores only what it is permitted to store—and avoids prohibited data—the breach payload is less useful.
From a threat-model angle, this matters because many fraud schemes rely on replay: stolen account number plus expiration date plus billing address, pushed into automated checkout bots. If the database dump lacks CVV2, the attacker either needs a second data source (phishing kits, malware logs, or another breach) or must target channels that don’t require the code.
In our own post-incident reviews (both for clients and for our own internal learning), we’ve seen that minimizing what exists in your systems is often the highest-return security move. It’s not glamorous, but it’s brutally effective: you can’t leak what you don’t have.
3. Why recurring billing or auto-pay can fail when a CVV2 is required each time
Recurring billing is where product expectations collide with compliance realities. Customers assume, “I saved my card, so you have everything you need.” Merchants assume, “If we have the card on file, we can always charge it.” Then a payment fails, and everyone blames the gateway.
What’s really happening is that CVV2 is not meant to be stored for reuse, and many payment flows intentionally do not require CVV2 on subsequent charges (because the merchant shouldn’t have it). When a merchant experience does require the code again, it can cause friction, customer confusion, and failed renewals—especially for subscription software, utilities, or membership programs where the entire point is “set it and forget it.”
From our perspective, the right solution is not to “store CVV2 anyway,” but to use the payment ecosystem’s intended recurring mechanisms: tokenized credentials, stored credential frameworks, and step-up authentication when risk warrants it.
4. Merchant security responsibilities often paired with CVV2: encrypted transmissions and ongoing security practices
CVV2 is only one piece of a larger security posture. Even if you handle CVV2 perfectly, other parts of the cardholder data flow can still be compromised by weak transport security, unsafe server configurations, or sloppy access controls.
PCI expectations also include securing card data in transit, and vendor documentation that summarizes PCI guidance (for example, HCL’s PCI-focused documentation) reiterates the need to use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks. In product terms, that means HTTPS everywhere for checkout pages, strict certificate handling, and a refusal to let payment data traverse “convenient” but insecure channels.
At Techtide Solutions, we also treat operational security as part of the payment feature, not separate from it. Access reviews, least-privilege policies, monitoring, and careful vendor selection are the difference between “we accept payments” and “we can defend payments.”
Security Benefits, Limitations, and Best Practices for Protecting Your CVV2
1. Security benefits: an extra layer of authentication for remote transactions
CVV2’s core benefit is straightforward: it adds friction for criminals who only have account numbers. It’s not a biometric, it’s not cryptographic authentication in the EMV sense, and it’s not proof of identity—but it is one more lock on the door.
In real-world commerce, that matters because many fraud attempts are opportunistic. Attackers try easy combinations first. Adding an extra required input can push a large set of low-effort attacks away from your checkout toward softer targets.
We also like CVV2 as a “user-aware” signal. Because the customer must actively supply it, it can reduce certain accidental misuse cases, like a coworker copying a saved card number from an invoice and attempting a purchase without having the card itself.
2. Limitations: phishing and malware can still capture CVV2 along with the card number
CVV2 is powerless against a buyer who is tricked into handing it over. That’s the uncomfortable truth. A fake checkout page that looks identical to a real merchant can harvest the card number, expiration date, and CVV2 in a single form submission, then replay them immediately on another site.
Government guidance on scams makes the broader pattern clear: the FBI warns that phishing pages can impersonate legitimate businesses and ask users to enter sensitive data like credit card information, as described in its overview of spoofing and phishing. Once the victim types the code into the wrong place, the “possession signal” is gone—because the attacker now has it too.
On the malware side, threats can be even quieter. Browser extensions, injected scripts, and compromised devices can scrape form fields in the background. This is why we don’t treat CVV2 as a “solution,” only as a helpful speed bump.
3. Safer usage habits: only share with trusted merchants, avoid being overheard, and use secure HTTPS websites
Security guidance for cardholders often sounds like common sense, but common sense is exactly what pressure and hurry destroy. In practice, safer CVV2 use comes down to a few repeatable habits that reduce exposure without turning shopping into paranoia.
Practical habits we recommend
- Prefer well-known merchants or verified platforms over sketchy pop-up stores that appear only through ads.
- Look for clear signs you are on the correct domain before typing payment information, especially when coming from email or text links.
- Avoid reading the code aloud in public spaces where conversations can be overheard, particularly in cafés, airports, or shared offices.
- Use mobile wallets when available, since they can reduce the need to type card data into a browser at all.
From our side as builders, we also encourage merchants to present “trust cues” responsibly: clear branding, consistent domain usage, and minimal third-party scripts on payment pages. Users should not have to be detectives to pay safely.
4. Personal protection steps: avoid saving card data online, strengthen passwords, secure Wi-Fi, use antivirus, and monitor reports and statements
CVV2 safety is inseparable from broader account hygiene. Attackers rarely rely on a single technique; they combine small wins across email compromise, password reuse, social engineering, and device infections. That’s why we recommend layered habits rather than a single “magic tip.”
Layered protections that actually hold up in the real world
- Whenever possible, avoid storing card details in unknown merchant accounts, especially if you don’t plan to shop there again.
- For accounts you keep, use unique, strong passwords and enable multi-factor authentication if the site supports it.
- On shared networks, avoid entering card details unless you trust the connection and the site is properly secured.
- Keep devices updated and protected so that “form scraping” malware and sketchy extensions have fewer openings.
- Regularly review bank alerts and card statements so that suspicious activity is caught early rather than after it snowballs.
At Techtide Solutions, we see this as a shared responsibility: cardholders should practice basic digital safety, while merchants should design systems that assume users are occasionally rushed, distracted, or tired—because they are.
TechTide Solutions: Custom Software That Supports Safer CVV2 Payment Flows
1. Designing secure web and mobile checkout UX that requests CVV2 appropriately for card-not-present purchases
Our strongest opinion here is simple: payment UX is security UX. A confusing checkout doesn’t merely lose conversions; it creates conditions where users make unsafe choices (like copying card details into notes or sending them over chat to “finish later”).
When we design CVV2 prompts, we focus on context. Does the user understand why the field exists? Do they know where to find it? Can the form adapt to the detected card brand? Can it fail gracefully when the issuer declines and the customer needs to retry without panic?
Importantly, we also design for restraint. If your business doesn’t need to request CVV2 for a particular transaction type (or if alternative authentication is in play), forcing the field can add friction without meaningful risk reduction. Security theater is still theater, even when it looks like compliance.
2. Building custom solutions that integrate payment gateways while minimizing sensitive-data exposure by design
On the engineering side, we aim to keep sensitive inputs out of merchant infrastructure. That typically means using gateway-hosted fields, client-side tokenization, and carefully scoped server endpoints that never receive raw CVV2. In well-architected systems, the merchant server receives a token or a payment-method nonce, not the card data itself.
In implementation reviews, we hunt for accidental collection points: verbose error logs, analytics events, form replay tools, and customer support consoles. Most CVV2 leakage is not “a hacker broke in”; it’s “we captured too much by default.”
From a delivery standpoint, we build guardrails into CI/CD: lint rules for logging, secure configuration templates, and environment-based controls that make it hard to accidentally ship “debug capture everything” code into production. Good teams are still human teams, and human teams need safety rails.
3. Adding layered fraud defenses beyond “what is CVV2 security code” checks, including monitoring and risk-focused workflows
Fraud prevention is not a single checkbox; it’s a feedback loop. CVV2 is one input, but real protection comes from correlation: device reputation, IP risk, velocity patterns, shipping/billing mismatches, user behavior anomalies, and post-transaction monitoring.
At Techtide Solutions, we like layered defense because it reduces false positives. If you rely too heavily on one brittle signal, legitimate customers get declined and fraudsters learn how to route around the control. In contrast, a risk-scored workflow can be more nuanced: approve low-risk transactions smoothly, step up authentication for mid-risk situations, and block high-risk activity decisively.
When we implement these systems, we also emphasize observability. Merchants need dashboards and alerting that show what’s happening: not in a vanity-metric way, but in a “can we spot an attack pattern quickly” way. The goal is a payment system that improves over time instead of repeating the same incidents on a loop.
Conclusion: What to Remember About What Is CVV2 Security Code
1. CVV2 primarily helps prove the buyer has the physical card during remote transactions
CVV2 is best understood as a possession check. It’s a short, printed secret intended to make remote fraud harder when the attacker only has copied account details. Used properly, it adds a meaningful layer to card-not-present transactions without requiring specialized hardware on the customer’s end.
At the same time, we don’t romanticize it. CVV2 is not identity verification, and it does not defeat modern phishing or device compromise. Treat it as one signal in a larger trust system, not as “the lock” on the door.
2. Knowing where the code is located (and what it may be called) prevents checkout confusion and errors
Most payment failures that look like “security issues” are actually clarity issues. Users don’t know which code to enter, where to find it, or why the form is asking for it. Merchants then see higher declines, higher support volume, and higher abandonment—none of which helps fraud outcomes.
Clear labeling, brand-aware helper content, and sensible error handling reduce confusion and reduce risky behavior. In our experience, that’s the hidden link between usability and security: when people feel confident, they stop improvising unsafe workarounds.
3. CVV2 works best when paired with broader security practices by both cardholders and merchants
Cardholders can reduce exposure by avoiding suspicious links, keeping devices secure, and limiting where card details are stored. Merchants can reduce risk by minimizing data exposure, using secure gateway patterns, and building fraud workflows that don’t depend on a single static secret.
So here’s the next-step question we ask clients (and ourselves) when we review a checkout: if an attacker gets the card number, what else would they need to succeed—and have we designed the system so that “everything else” is genuinely hard to obtain?
