Card Issuing Product Spec Template

What This Template Is For

Card issuing is one of the most complex product domains in fintech. You are building on top of payment networks (Visa, Mastercard), working with BIN sponsors and processor partners, managing real-time authorization decisions, handling chargebacks, and complying with PCI-DSS at every layer. A missed edge case in authorization logic can mean fraudulent transactions going through or legitimate purchases being declined.

This template helps product managers spec out card issuing features for physical cards, virtual cards, or both. It covers card lifecycle management, authorization controls, spend rules, 3D Secure authentication, dispute workflows, and card program configuration. Whether you are building an expense management platform, a neobank debit card, or an embedded finance product with cards-as-a-service, this template gives you a structured starting point. Pair it with the financial product PRD for the full product context and the payment flow spec for the money movement layer.

How to Use This Template

1. Copy the template into your documentation tool.
2. Start with Card Program Configuration. Your BIN sponsor and processor determine what is technically possible.
3. Define card types (physical/virtual) and their lifecycle states.
4. Spec authorization controls and spend rules. These are the core product decisions.
5. Define 3DS, dispute, and fraud flows.
6. Review with engineering, the BIN sponsor, your processor, and compliance.
7. Use the RICE Calculator to prioritize which card features to build first.

The Template

Card Program Configuration

Program economics:

Card Types

Physical Cards

Virtual Cards

Card Lifecycle

States:

CREATED → INACTIVE → ACTIVE → SUSPENDED → CLOSED
ACTIVE → LOST/STOLEN → REPLACEMENT_ISSUED → ACTIVE (new card)
ACTIVE → EXPIRED → RENEWAL_ISSUED → ACTIVE (new card)

State transition rules:

Card replacement logic:

• Lost/stolen: Issue new card with new PAN. Transfer digital wallet tokens.
• Expired: Issue new card with new PAN and new expiry. Migrate recurring merchant tokens.
• Damaged: Issue new card with same PAN (if possible) or new PAN.

Authorization Controls

Authorization is the core product decision engine. Every card transaction flows through your authorization logic in real-time (typically < 100ms response required).

Just-in-time (JIT) funding flow:

1. Cardholder taps/swipes card at merchant
2. Card network routes authorization request to processor
3. Processor sends webhook to your platform
4. Your platform evaluates spend rules (< 50ms)
5. Your platform responds: APPROVE or DECLINE
6. Processor relays decision to card network
7. Merchant receives approval/decline

Authorization decision inputs:

Spend Rules

Rule types:

Rule evaluation order:

1. Card status check (active?)
2. Balance check (sufficient funds?)
3. Velocity checks (daily/monthly limits)
4. MCC rules (allowed category?)
5. Geography rules (allowed country?)
6. Time rules (within active window?)
7. Fraud score check (below threshold?)
8. Custom business rules
9. APPROVE or DECLINE with reason code

Decline reason codes:

3D Secure (3DS) Authentication

3DS flow:

1. Cardholder initiates online purchase
2. Merchant sends 3DS authentication request
3. Your system evaluates risk (frictionless vs. challenge)
4. If frictionless: authenticate silently, return success
5. If challenge: send push notification to cardholder app
6. Cardholder approves in app (biometric or PIN)
7. Return authentication result to merchant
8. Merchant proceeds with authorization

Dispute and Chargeback Handling

Dispute workflow:

TRANSACTION → DISPUTED (cardholder reports) → UNDER_REVIEW
UNDER_REVIEW → PROVISIONAL_CREDIT_ISSUED → INVESTIGATION
INVESTIGATION → RESOLVED_IN_FAVOR (credit permanent)
INVESTIGATION → RESOLVED_AGAINST (provisional credit reversed)
INVESTIGATION → ESCALATED (representment to network)

Dispute categories:

Dispute intake fields:

• ☐ Transaction ID (pre-populated from transaction history)
• ☐ Dispute reason (dropdown by category)
• ☐ Description (free text, max 500 chars)
• ☐ Supporting documents (photo upload, max 3 files)
• ☐ Expected resolution (refund / replacement / investigation)

Fraud Prevention

Fraud alert triggers:

• ☐ Transaction in a new country (first-time)
• ☐ Transaction > 3x average transaction amount
• ☐ Multiple declined attempts in 5 minutes
• ☐ Card-not-present transaction after recent card-present in a different city
• ☐ Transactions at 3+ merchants within 10 minutes

Cardholder Notifications

Reporting and Admin

Cardholder dashboard:

• ☐ Transaction history with search and filters
• ☐ Spending breakdown by category
• ☐ Monthly statement generation (PDF)
• ☐ Card details view (masked PAN, expiry, CVV reveal)
• ☐ Spend rule management interface
• ☐ Dispute submission and tracking

Admin dashboard:

• ☐ Card inventory management
• ☐ Bulk card issuance
• ☐ Spend rule templates
• ☐ Transaction search and investigation tools
• ☐ Dispute queue and resolution workflow
• ☐ Program-level analytics (volume, interchange, fraud rate)
• ☐ Cardholder account management

Compliance Requirements

Review the fintech compliance checklist for a full regulatory audit. Refer to the glossary entry on compliance for definitions of key regulatory terms.

Launch Checklist

• ☐ BIN sponsor agreement signed and program ID assigned
• ☐ Processor integration tested end-to-end (auth, clearing, settlement)
• ☐ JIT funding webhook response time < 100ms at P99
• ☐ Spend rules engine validated against 100+ test scenarios
• ☐ 3DS authentication flow tested with major merchants
• ☐ Physical card fulfillment and shipping tested
• ☐ Digital wallet provisioning tested (Apple Pay, Google Pay)
• ☐ Dispute workflow tested with all reason code categories
• ☐ Fraud rules calibrated (false positive rate < 5%)
• ☐ Cardholder notifications tested across all channels
• ☐ PCI-DSS audit completed (or processor attestation obtained)
• ☐ KYC/AML integration verified
• ☐ Admin dashboard reviewed by operations team