How to Build a Pharmacy Discount Card

What happens when a patient uses a discount card

When a patient presents a discount card at the pharmacy counter, here's the actual technical flow:

The entire round-trip takes 2–5 seconds. Every major pharmacy in the US processes claims this way. It's the universal protocol.

The three numbers that make it work: BIN, PCN, and Group

Every discount card has three critical identifiers. Understanding them is essential:

Beyond these three, each card also has a Member ID (unique per cardholder) and a Person Code (01 for primary, 02 for spouse, 03+ for dependents).

Traditional approach: 6 months and $500K+

Historically, launching a discount card program required:

Total cost: $300K–$500K+ in engineering time, plus ongoing switch fees, PBM fees, and maintenance. That's before you've signed a single customer.

The API approach: launch in weeks

Starlight API eliminates the infrastructure layer. Instead of building an NCPDP stack, you send JSON:

// Check if a member's card is valid before they visit the pharmacy
const eligibility = await fetch('https://starlight.claims/api/v1/submit', {
  method: 'POST',
  headers: {
    'X-API-Key': 'your_api_key',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    transaction_type: 'E1',
    patient: {
      first_name: 'JANE',
      last_name: 'DOE',
      date_of_birth: '19850615'
    },
    insurance: {
      bin_number: '610341',      // Your assigned BIN
      pcn: 'DISCOUNT',           // Your program PCN
      group_id: 'EMPLOYER001',   // Employer or plan group
      cardholder_id: 'MBR12345', // Member's card number
    }
  })
});

const result = await eligibility.json();
// result.header.responseStatus === 'A' → member is eligible

When it's time to process an actual claim at the pharmacy counter, Starlight handles the NCPDP encoding, switch routing, and response parsing. You focus on your product (pricing logic, member management, pharmacy network), not infrastructure.

Architecture for a discount card startup

Here's the minimal architecture you need:

Revenue model: how discount cards make money

Understanding the economics is critical for building a sustainable business:

• • Spread pricing: You negotiate rates with pharmacies (e.g., AWP - 80% + $2.00 dispensing fee) and charge patients slightly more. The spread is your revenue. Typical margin: $3–$8 per claim.
• • Per-transaction fees: Some models charge pharmacies a per-claim processing fee (typically $0.10–$0.25).
• • Employer-funded: Employers pay a per-employee-per-month (PEPM) fee for their workforce to have access to discounted prescriptions. Typical PEPM: $2–$5.
• • Affiliate/referral: Earn fees by directing patients to specific pharmacies. Common in the GoodRx model.

At scale, even $3/claim margin across millions of monthly claims generates significant revenue. GoodRx processes ~100M claims/year.

Common technical pitfalls

• • BIN routing errors: If your BIN isn't properly registered with all major switches, pharmacies in certain regions won't be able to process your card. Test across multiple pharmacy chains before launch.
• • Reject code handling: NCPDP defines 100+ reject codes. Your system needs to handle each one gracefully: refill-too-soon (79), drug not covered (70), prior auth required (75), and dozens more.
• • Coordination of Benefits (COB): When a patient has both insurance and your discount card, the claim flow gets complex. Build clear logic for when to bill primary insurance vs. your discount program.
• • State regulations: Some states have specific requirements for discount card programs (registration, disclosures, fee caps). Check your target states before launch.

Related guides

• • BIN PCN Lookup API — understand the routing identifiers your card needs
• • How to Submit Pharmacy Claims via API — the claims submission your card program will use
• • Insurance Eligibility Verification API — check if the patient has primary insurance first
• • Pharmacy Claims Processing Workflow — how discount card claims flow through the system