Linque
Find cards a shopper already holds using their name and mobile number, and let them pay without typing a card number.Most guest shoppers arrive with no card on file and a card in their pocket. Typing a card number on a phone is where checkouts stall. Linque removes that step. From a name and a mobile number, it finds the cards the shopper already holds, lets them tap one, and hands you a Basis Theory token you charge through the processor integration you already use.
- Fewer abandoned checkouts. The shopper confirms a text message and taps a card instead of typing a number, an expiry and a security code.
- Works on the first visit. No account, no saved card, no wallet to enroll in. Discovery runs on information the checkout already collects.
- No new PCI scope. The code, the security code and the card stay inside Basis Theory iframes. Your page sees a token and the last four digits.
- Your stack stays the same. The token lands in your tenant and charges like any other Basis Theory token, so your processor, fraud tools and reporting are untouched.
- One payment path. The wallet renders manual card entry when discovery finds nothing, so you ship one Pay handler for every shopper.
Start with a Guide
Linque Setup
Implementation
Testing Reference
How it Works
A checkout has four steps.
- Identify the shopper. Send their name and mobile number. Linque sends a verification code by SMS.
- Verify the phone. The shopper enters the code. Linque returns the shopper and their discovered cards, including artwork, issuer, network, last four digits, and whether each card requires a security code.
- Choose a card. The shopper selects a card and, when required, enters its security code. The security code proves they hold the card. Without it, the card is not verified.
- Use the card. Linque creates a Basis Theory token in your tenant from the verified card and returns it. The card number never reaches your page, and your application never needs it unless you reveal the token with a private key.
Some cards can be verified without a security code. The discovered card tells you whether one is required and how many digits to collect before you render the field.
With Elements, the verification element collects the code and the wallet element renders the discovered cards and the security code field. The code, the session key and the verified card stay inside Basis Theory-controlled iframes. With the API, your backend drives the same four steps with a private key.
Discovery should enhance checkout, not become a dependency of it. If Linque finds no cards, or a discovered card cannot be verified, the shopper should still be able to enter a card manually. The wallet element renders manual card entry for those cases, so your checkout needs only one payment path.
Overview
What You Get
A card the shopper has proven they hold. A code proves the phone and a security code proves the card, so what you charge is a card its issuer has confirmed belongs to the person paying. Verifying it creates a card token in your tenant, with your application as created_by. The token carries the brand, last four digits and expiration for display. The card number stays in the vault.
getCard returns the token for a discovered card, and element references for a discovered or a manually entered card. One Pay handler covers both.
A publishable key runs the whole flow and never receives a card number. The session key that scopes a shopper's cards is issued only after the phone is verified, and it expires on its own.
Coverage
Linque discovers cards for shoppers with a United States mobile number. Card availability varies by issuer and other eligibility factors. Some shoppers have no discoverable cards, and some discovered cards cannot be verified. Both are normal checkout outcomes, and the shopper continues with manual card entry.
What It Does Not Do
Linque does not charge the card and does not return processor or network tokens. It returns a Basis Theory token. Everything after that is your existing integration.