Card type detection
Understand how DEUNA detects card types and keeps routing conditions consistent across configuration surfaces.
On this page
Card type detection and consistency in routing across the DEUNA Admin ensures accurate detection and usage of card types across critical areas:
- Routing strategies: Routing decisions respect the card type derived from the BIN detector.
- Admin (Merchant order details): Card type displayed accurately reflects what was used in the transaction.
Data consistency#
Information regarding card type is stored in the card_type field and is available across all products where method_type has an impact.
Objectives of card detection:
-
Support for
"credit","debit"and"prepaid"card types in routing conditions, using the BIN detector. -
When the BIN detector cannot recognize the card type, the value will be returned as
"unknown_card". -
Display the correct card type in the DEUNA Admin, based on the BIN detector.
-
Ensure consistent usage of the correct card type across order processing, routing, reporting, and responses on the DEUNA ecosystem.
Card type support#
The BIN detector service recognizes the card six digits of the card number.
The Routing Engine recognizes and supports the following card types:
credit_carddebit_cardprepaid_card
Routing behavior follows standard rule evaluation. If a rule targets debit cards and the BIN detector identifies the card as a debit, then the standard rule applies.
Card type recognition works for all DEUNA flows like:
- Incoming raw card details
- Tokenized DEUNA cards
- Cards tokenized with DEUNA and with PSP
Example:
json
CopyEdit
"conditions": [
{
"rule_option": {
"label": "method_type"
},
"operator": "in",
"operand": "debit_card"
}
]Card type rendering#
In the DEUNA Admin, the values are parsed from the BIN detector:
The BIN detector extracts the information from the card number and standardizes it: If the value is:
CREDITforcredit_card, then the detector displays"credit_card"DEBITfordebit_card, then the detector displays"debit_card"PREPAIDforprepaid_card, then the detector displays"prepaid_card"UNKNOWNforunknown_card, then the detector displays"unknown_card"
"from_card": { // card object
"bank_name": "Santander",
"country_iso": "MX",
"credential_source": "f",
"expiry_month": "11",
"expiry_year": "2031",
"card_type": "debit_card"
}Response compatibility#
For integrations that require a different response contract, DEUNA can return card method types without the _card suffix and can normalize the diners brand value to diners_club. Apply one response convention consistently across environments so consumers do not need to accept two shapes.