# A retailer taking control of card costs

A US omnichannel retailer with stores and an online shop.

**Illustrative scenario.** A fictional type of business, not a customer. No results are claimed.

Cohorts: Fi + Vs

## The problem

Card fees arrive as one blended number. Nobody can say why a payment went to one processor and not another, or what debit routing would save.

## Value anatomy

1. **Transaction**: Card payments run through rules the retailer writes: by card type, channel and amount.
2. **Rails**: Eligible debit goes to the network the rules choose. A second acquirer takes a share of traffic in a parallel run.
3. **Record**: Every payment shows its route, its rule and its fee lines, so finance can model the next change before making it.

## What it uses

- **Routing rules**: Rules by card type, region, amount or time. Reviewable and reversible.
- **Debit network choice**: Send eligible debit to the network your rules pick.
- **Multi-processor acceptance**: Run more than one acquirer behind one integration.
- **Parallel run**: Mirror live traffic next to your current setup and compare each payment.
- **Cost modelling**: Preview a routing or payout change before you make it.
- **Fee lines**: Network, scheme and insimbi fees, itemized per transaction.

Request access: sales@insimbi.net

_insimbi is in early access with design partners._