Card order tracking
D1 sends real-time production and shipment updates for physical cards to your issuer backend.
Use notifications (webhooks), on-demand status, or both.
High-level flow
Status transitions
This diagram shows typical transitions from request to shipment.
It also includes exception and on-hold paths.
How it works
Use one or both approaches.
Receive notifications for each production step and shipment update.
Handle at-least-once delivery. Expect retries and duplicates.
Implement the callback endpoint defined in Backend notifications.
Query the current production/shipment status at any time.
Required APIs
API content
Notifications and on-demand responses use the same operation object.
They can include:
operationId
Unique identifier for the operation instance. Use it for de-duplication and correlation.
Required
operation
Operation type. Always PRODUCE for physical card issuance tracking.
Required
status
Operation status: PENDING, SUCCESSFUL, or FAILED.
Required
startTime
ISO 8601 timestamp when the operation started.
Required
endTime
ISO 8601 timestamp when the operation completed.
Conditional
cardId
Internal card identifier in D1.
Required
errorCode
Machine-readable failure cause.
Conditional
error
Short human-readable failure description.
Conditional
inputFileName
File name containing card issuance requests.
Conditional
issuerRequestId
Correlation identifier provided by your issuer backend.
Conditional
Top-level status is the operation status.
details.status is the physical card issuance status.
Delivery and idempotency
Notifications can arrive out of order, and more than once.
Use
operationIdto de-duplicate and correlate events.Use
startTime/endTimeto decide which event is the latest.Use the on-demand API to reconcile state if you detect gaps.
Last updated
Was this helpful?