I work in the debit side of things (well for only about the next few months) so my experience is a tad bit different, I'll approach it from a debit perspective, credit should be somewhat similar.
The device you swipe your card at Best Buy is a merchant device. Best Buy has made an agreement with the device vendor to route its traffic over a specific network, say First Data.
When you swipe the card the network(gateway) decides where to 'route' the request based on the BIN (typically first 6 digits of the card number, can be more depending on how the card profile is setup). The network has BIN tables setup so they can easily identify which cards go where. After the merchants gateway has determined where to route the card, the request then propagates to the issuing network, from there it is sent to the issuer to approve/deny the request.
This is a simple high level overview and by no means complete.
Ex. path
User swipes card @ device
-> Merchant devices sends transaction to First Data (where FDC is the merchant device gateway)
-> First Data routes transaction to issuing network (Visa, MC, Cirrus)
-> Issuing Network forwards request to issuer (issuance processor) for approval
In debit world, it used to be that the more 'hops' a request took to route back to the issuer, the more that interchange that was incurred.
There are all sorts of scenarios that can occur, for example, I'm working on a project that would circumvent the networks if the transaction is for a card issued by our bank (closed loop transaction), which avoids interchange fees paid to the network.
The device you swipe your card at Best Buy is a merchant device. Best Buy has made an agreement with the device vendor to route its traffic over a specific network, say First Data.
When you swipe the card the network(gateway) decides where to 'route' the request based on the BIN (typically first 6 digits of the card number, can be more depending on how the card profile is setup). The network has BIN tables setup so they can easily identify which cards go where. After the merchants gateway has determined where to route the card, the request then propagates to the issuing network, from there it is sent to the issuer to approve/deny the request.
This is a simple high level overview and by no means complete.
Ex. path
User swipes card @ device -> Merchant devices sends transaction to First Data (where FDC is the merchant device gateway) -> First Data routes transaction to issuing network (Visa, MC, Cirrus) -> Issuing Network forwards request to issuer (issuance processor) for approval
In debit world, it used to be that the more 'hops' a request took to route back to the issuer, the more that interchange that was incurred.
There are all sorts of scenarios that can occur, for example, I'm working on a project that would circumvent the networks if the transaction is for a card issued by our bank (closed loop transaction), which avoids interchange fees paid to the network.