Card Issuing API: An Integration Acceptance Checklist

This checklist helps engineering leads turn business requirements into acceptance tests. It separates five evidence layers: the request, the immediate response, the later card state, transaction records, and reconciliation. For this checklist, reconciliation means comparing the agreed financial records and investigating differences. Use the accompanying worksheet to record questions and missing evidence before implementation.

Terminology sources: MDN Web Docs, “API” (API terminology), accessed October 14, 2026. Stripe, “Accounting reconciliation: What it is and how it’s done” (general accounting explanation), accessed October 10, 2026.

Start with a business action

Describe the outcome your business needs before asking for an API feature list. For example, define one card for an approved advertising budget, associated with its internal spending purpose. This is a proposed requirement, not a supported API field or a promise that a provider can meet it.

For each action, record who approves it, who submits it, and who decides whether it succeeded. Define what must happen when the result is missing or contradictory. A technical response, a visible card, and a finance record answer different questions.

Limit the initial scope to your own company's spending workflows. If you need an introduction to issuers, card networks, and issuing platforms, read the card issuing guide. Return here to test the integration boundary for your chosen workflow.

Assign responsibilities before implementation

The following split is a starting proposal. Your contract and named contacts must settle the actual responsibilities; the worksheet does not assign legal or regulatory obligations.

Engineering should review automatic retries in the client, job runner (software that runs scheduled or background tasks), and notification processing against the agreed contract. A planning decision to hold further submissions will need an operational implementation. Recording that decision in a worksheet does not stop software from sending requests.

Terminology source: RQ, “Workers” (a background-worker example), accessed October 14, 2026. This reference does not establish your provider’s runtime behavior.

Proposed responsibility split; agree the actual roles and evidence routes in your contract.

Separate the API from the dashboard

HaiPay publishes this article. The capability summary below reflects first-party product confirmation dated October 10, 2026; it is not an independent integration test or an API contract.

Source: HaiPay, “Virtual Cards for Business: Ad Spend & AI Tools” (first-party product overview, not an API specification), accessed October 14, 2026. Capability scope was separately confirmed first-party on October 10, 2026.

Terminology sources: RFC Editor, RFC 4180 (CSV format); Stripe, “Sandboxes” (its own controlled test environment). Both accessed October 14, 2026. These references do not establish your provider’s test access or scenario coverage.

Verify notifications and controls

A webhook is a notification sent to an agreed receiving system. Confirmation that webhook notifications exist does not establish their delivery timing, ordering, completeness, or retry behavior. Ask for the applicable contract and test cases.

Terminology source: Stripe, “Receive Stripe events in your webhook endpoint” (its own notification model and delivery conditions), accessed October 10, 2026.

Likewise, a dashboard limit control does not prove that an API can set that limit when creating a card. A dashboard closure action does not establish an API closure operation. Verify each required action in its own channel.

Test five layers of evidence

Use the same business action across all five layers. Do not replace a missing layer with evidence from a different one. The proposed tests below must be adapted to the documented provider contract.

Finance must decide which financial records matter for each action. Do not assume that creating, freezing, or closing a card has a particular effect on fees, funding, pending transactions, or settled amounts. Those questions require the applicable terms and finance review.

Five separate evidence layers, not an event timeline or a guaranteed provider lifecycle.

Fill the acceptance worksheet

Open the local planning tool, download the blank CSV, or inspect the synthetic timeout sample. These links refer to files in this delivery package; production download locations still need to be assigned.

The worksheet has 18 planning fields, not provider API parameters. Fill it in this order:

1. Start with one row per business action. Name the internal owner and provider contact, then record the interface or event you need to verify.
2. Attach redacted evidence references rather than credentials, personal details, or card numbers. Work through the five layers and define success and failure tests.
3. Record unresolved questions and complete the decision fields. Name the first verifier, original-operation-to-resource evidence, hold trigger, and condition for a later action.
4. Leave missing evidence visible. An unanswered question is not an acceptance pass.

The tool is a planning aid. Its sample and status labels do not authenticate provider evidence, approve a retry, or supply engineering or finance sign-off. Use its exports as review records, then agree and implement the controls in your actual systems.

Walk through a timeout with an unknown result

Synthetic example: no real provider request, card, event, transaction, or finance record is represented. Your application submits a request to create one card. The caller times out before receiving a usable response. The only established observation is the caller's timeout; delivery and execution remain unresolved.

1. Hold further submissions and name the verifier

For this proposed acceptance scenario, hold further creation attempts as soon as the result becomes unknown. The internal engineering lead checks the redacted attempt history first, then asks the designated provider technical contact to investigate the original operation. Include the attempt timeline and time zone, any permitted reference already available, and the intended business outcome.

2. Link the original operation to any resulting card

The investigation needs evidence connecting the original attempt to any resulting card, plus current-state evidence through an agreed route. A local identifier alone does not prove that repeating the request is safe. No transaction record, no visible notification, or a later connection recovery is not sufficient proof that creation failed.

Public documentation illustrates why the distinction matters. Advanced error guidance explains that restored connectivity cannot determine the original outcome. Its replay guidance has version-specific conditions. An idempotent API discussion describes contracts designed to avoid unintended repeated effects and service-dependent retention requirements. These are industry references, not implementation guarantees for your issuing provider.

Source: Stripe, “Advanced error handling” (its own API conditions), accessed October 14, 2026; AWS, “Making retries safe with idempotent APIs” (architecture examples), accessed October 14, 2026.

3. Record the decision and unresolved escalation

Before any further action, resolve the original outcome and apply a documented provider procedure reviewed by engineering. If the evidence remains missing or contradictory, keep the hold and escalate to the named provider contact. Finance separately reviews any financial evidence relevant to the action. This desk walkthrough ends unresolved; it does not establish provider retry, event, or financial semantics.

Synthetic planning scenario, not a live request or evidence of HaiPay retry, event, or financial behavior.

Turn the worksheet into a review handoff

Before approving implementation, ask engineering to review the actual access method, supported operations, tracing, configured retry behavior, notification handling, and recovery tests. Ask finance to review the applicable record definitions and reconciliation cases. The business owner should confirm the spending purpose and permitted scope.

Keep the completed worksheet, supporting evidence, unresolved questions, and named decisions together. Agree what blocks implementation and what must be tested before production use. The worksheet is useful only when those decisions become concrete acceptance criteria for the real integration.

For confirmed product scope and an integration discussion, visit the card issuing product page. Bring your business actions and evidence questions so the conversation can address the required boundaries. This article is technical evaluation guidance, not investment advice or a completed production approval.

Sources

1. Stripe: Advanced error handling — public technical reference; accessed October 14, 2026.
2. AWS Builders' Library: Making retries safe with idempotent APIs — public architecture reference; accessed October 14, 2026.
3. HaiPay: Virtual Cards for Business: Ad Spend & AI Tools — public context and consultation route; accessed October 14, 2026. It is not the dated product confirmation or an API specification.
4. MDN Web Docs: API — API terminology; accessed October 14, 2026.
5. Stripe: Accounting reconciliation: What it is and how it’s done — general accounting explanation; not provider-specific financial semantics; accessed October 10, 2026.
6. RQ: Workers — background-worker example; no provider runtime claim; accessed October 14, 2026.
7. RFC Editor: Common Format and MIME Type for Comma-Separated Values (CSV) Files (RFC 4180) — CSV format reference; accessed October 14, 2026.
8. Stripe: Sandboxes — its own controlled test environment; not your provider’s access or scenario coverage; accessed October 14, 2026.
9. Stripe: Receive Stripe events in your webhook endpoint — its own notification model and conditions; not provider delivery guarantees; accessed October 10, 2026.

Product scope above uses dated first-party confirmation. The linked public references establish their own examples and limitations, not your issuing provider's interface contract.