Merchant-Locked Payment Codes: Trade-offs and a Buggy Checker

A card issuer wants to add merchant-locked payment codes inside its mobile app. A cardholder spins up a 12-digit code against their real account, pins it to exactly one merchant, and uses it only there until it either lapses on its own or the cardholder kills it manually. The exercise has three linked stages: talking through the feature, walking through sample codes by hand, and fixing a broken piece of validation logic built from the same rules.

Code layout for this exercise

A code runs 12 digits long, positions 1 through 12 counted from the left. Here's what governs each segment:

A code is only acceptable if every one of those five checks comes back clean.

Clarifying Questions

• Does a human ever manually key in the 12 digits, or does it always move between systems programmatically?
• Is a cardholder allowed more than one live code simultaneously, say one per subscription?
• When walking through samples by hand, do you report just the first broken rule, or everything a code violates?
• Should the sample payments be worked through in the order they're listed?

Part 1 — Trade-offs for cardholder and issuer

Walk through what a merchant-locked code is worth, and what it costs, on both sides of the relationship — the cardholder using it and the issuer running it — by tracing one code from creation through everyday purchases, a refund, and eventual cancellation.

Part 2 — Validate by hand

Using the table above, decide which of these codes are acceptable, assuming today's payment date is March 15, 2026:

1. 107261402126 — claimed merchant ID 40212, currency USD
2. 207260402137 — claimed merchant ID 40213, currency USD
3. 113261402123 — claimed merchant ID 40212, currency USD
4. 101261402120 — claimed merchant ID 40212, currency USD

For each, state which rule (if any) it fails, and show the check-digit arithmetic.

Part 3 — Debug a flawed validator

Below is a validator meant to implement the same five rules. It has three independent bugs — a wrong boundary comparison, an inverted condition, and an off-by-one in which digits get summed for the check digit. Find all three and explain, for each, a specific input that the buggy code gets wrong.

def validate_code(code, payment_date, merchant_id, currency):
    if len(code) != 12 or not code.isdigit():
        return False
    digits = [int(c) for c in code]

    if digits[0] not in (1, 2):
        return False

    mm = digits[1] * 10 + digits[2]
    yy = digits[3] * 10 + digits[4]
    if not (1 < mm < 12):
        return False
    year = 2000 + yy
    expiry_end = last_day_of_month(mm, year)
    if payment_date > expiry_end:
        return False

    currency_map = {1: "USD", 2: "EUR", 3: "GBP"}
    if digits[5] in currency_map and currency_map[digits[5]] == currency:
        return False

    locked_id = "".join(str(d) for d in digits[6:11])
    if locked_id != merchant_id:
        return False

    check = sum(digits[0:12]) % 10
    if digits[11] != check:
        return False

    return True