Routing on BIN metadata & normalized fields
Two ways to make a routing decision portable across gateways: BIN metadata tells you about the card itself, and normalized fields give request and response data the same name regardless of which gateway a path uses.
Get card data onto the canvas
To route on card attributes, add Get Payment Method Info as a step before your Decision step. It looks up the payment method from its token and adds the card's details to the canvas, where Decision steps can use them as conditions.
You only need this step when a decision depends on the card. If your routing uses other request data – such as currency, amount, or a value you send – you don't need it.
BIN metadata
BIN metadata is card-level data – brand, issuing bank, issuing country, card type, and more – derived from the card's BIN (its first six-plus digits). It's available automatically for any org with Advanced Vault enabled at the organization level; you don't need to enroll an individual payment method in Advanced Vault to use it. It's supported for card payment methods only – not wallet methods like Apple Pay or Google Pay.
| Field | Description |
|---|---|
| card_brand | Visa, Mastercard, Discover, etc. |
| card_type | Credit, Debit, Charge Card |
| card_category | B2B, Prepaid, Personal Platinum Revolve, etc. |
| issuing_bank | The bank that issued the card |
| issuing_country_iso_name issuing_country_iso_a2code issuing_country_iso_a3code issuing_country_iso_number | Issuing country, in four ISO formats |
| issuing_bank_phone_number / issuing_bank_website | Issuer contact info |
| bin_type | Commercial or Personal |
| regulated | Y/N – whether the issuing bank's assets exceed $10B |
| max_pan_length | Maximum PAN length for the BIN |
Full reference: BIN Metadata
Using it in a Decision step
Make sure Get Payment Method Info runs before the Decision step that uses these fields. Condition on payment_method.bin_metadata.card_type to route debit differently from credit, or on issuing_country_iso_a2_code to route by region. If your org isn't enrolled in Advanced Vault, Composer omits these fields and returns a message that BIN metadata requires Advanced Vault, rather than gating the decision itself – anyone can build the condition, but the data only populates for enrolled orgs.
Normalized fields
Normalized fields are request and response fields Spreedly standardizes across gateways – things like risk_data, customer_data, merchant_metadata, and order_data on the way in, and gateway_response (with card_metadata, payment_outcome_data, etc.) on the way out. They're available today via API, and coverage is per-gateway, not the full list. Full field-by-field mapping per gateway: Normalized request and response fields.
Why it matters for routing: If two branches of a checkpoint route to different gateways, using the normalized field names (rather than each gateway's own field names) means the same step configuration and the same downstream decision logic work regardless of which branch a transaction takes.
Updated 30 minutes ago