Debit card issuing, end to end
Create the card, get it to the cardholder, then run it — the three stages of a debit programme in the order you call them.
Where this comes fromCompiled from the debit card issuing service list maintained by the integration team, checked against the compiled specifications. The sequence is theirs; the endpoint names, methods and activity classifications are read from the specifications rather than restated.
What this is for
- Launching a debit programmeThe order the three stages happen in, and which endpoint does each part.
- Scoping the delivery integrationWhat the courier stage needs from you, and what it hands back.
The call sequence
Card creationalternatives
Pick the one that matches the card you are issuing — these are alternatives, not a sequence. Nothing else in this flow can run until one of them has returned a card.
/debit/api/createIndividualCard
Create Individual Card
createIndividualSupplementaryCard
createDummyCorporateCard
/debit/api/createCorporateCard
Create Corporate Card
POST/debit/api/createVirtualCard
Create Virtual Card
Delivery
Only physical cards reach this stage, and this one does run in order. The barcode number is the courier's and identifies the shipment, not the card — one shipment may carry several.
/delivery-integration-indoor-service/api/createDeliveryFile
Create Delivery File
POST/delivery-integration-indoor-service/api/getCourierInformation
Get Courier Information
POST/delivery-integration-indoor-service/api/updateAddressInformation
Update Address Information
POST/delivery-integration-indoor-service/api/updateMovementsWithBarcodeNumber
Update Movements With Barcode Number
Life cyclealternatives
Everything after the cardholder has the card. These are not sequential — call what the journey needs.
/debit/api/setRsaPin
Set Rsa Pin
POST/debit/api/changeCardStatus
Change Card Status
POST/debit/api/replaceCard
Replace Card
POST/debit/api/getCardPermissions
Get Card Permissions
POST/debit/api/saveCardPermissions
Save Card Permissions
POST/debit/api/setCardOperationLimit
Set Card Operation Limit
POST/debit/api/addDebitCardLog
Add Debit Card Log
POST/debit/api/attachCardAccount
Attach Card Account
POST/debit/api/detachCardAccount
Detach Card Account
POST/debit/api/modifyCardAccount
Modify Card Account
POST/debit/api/getCardList
Get Card List
Before you start
Every call in this flow needs a bearer token from the security token service, and every one is a
POST — including the reads. Base URLs are not written into this page: pick the environment from
the switcher in the header, and only Sandbox is published today.
The three stages are not equally documented. Card creation and life cycle sit in the debit API and carry its full compiled detail. Delivery is a separate service whose own document has no endpoint section, so its four operations here are described from their specifications and from the sequence they belong to — enough to scope the integration, not enough to build the request bodies from.
What the delivery stage assumes
A card reaches distribution only after it has been produced. createDeliveryFile is the handover,
not part of issuance, and nothing before it produces a barcode number — so getCourierInformation
answers nothing for a card that has not yet left production.
Virtual cards never enter this stage. If your programme is virtual-only, the flow is two stages, not three.
Two endpoints are not in the specification
The issuing service list names createIndividualSupplementaryCard and createDummyCorporateCard.
Neither appears in the compiled debit specification, so neither has a page, a field table or a
sample on this portal. They are shown in the sequence above because they are part of the flow as
the integration team runs it, and marked because the portal will not claim an endpoint exists on
the strength of a spreadsheet.
Both are worth confirming before you plan against them. createDummyCorporateCard in particular is
filed as the corporate main card while createCorporateCard — which does exist — is filed as the
supplementary one, and the two labels look transposed.
What this flow does not cover
Applications and eligibility come before it: see the debit card applications guide for what happens between a customer asking for a card and a card being created. Statements, disputes and settlement come after it, and belong to their own capabilities.
Capabilities it covers
- 21 operationsCard issuance and personalisationCreate individual, corporate and virtual cards, and check which products a customer is eligible to hold before you issue.
- 7 operationsCard delivery and courier trackingGet a produced card to the cardholder — generate the distribution file, track the courier by barcode, and correct the delivery address while the card is in transit.
- 34 operationsCard lifecycleMove a card through its states after issuance — status changes, replacement, renewal, blocking and closure.
- 44 operationsPIN and card securitySet and change a PIN, manage the try counter, and generate or verify the card verification values.
- 12 operationsPermissions and restrictionsTurn individual capabilities on and off for a card — e-commerce, international use, mail order and other miscellaneous options.
- 18 operationsCard and customer limitsRaise, lower and reverse the spending limit on a card or on the customer behind it. Every change returns a log id you can reverse with.
- 22 operationsAccount linkingAttach and detach the accounts a card draws on, and read back what a card is currently linked to.