Astrada Platform Customer Support — Frequently Asked Questions

Last updated: June 2026 | [email protected] | docs.astrada.co

This document covers the most common questions we receive from Astrada integration partners and end users. If your issue is not addressed below, please start by visiting docs.astrada.co for full technical documentation, then post in your dedicated Slack channel if needed, or reach out to our support team at [email protected] if your issue remains unresolved.

Transactions — Q1–Q5
Card Enrollment & Connection — Q6–Q8
Webhooks & Notifications — Q9–Q11
Refunds & Credits — Q12
API & Integration — Q13–Q14
Supported Cards & Coverage — Q15–Q17
Virtual Cards — Q18
Transaction Data Visibility — Q19–Q20
Card Lifecycle — Q21–Q22
Testing — Q23

1. Transactions

Q1 — A transaction that appears on my bank statement is missing from the Astrada platform. Why?

There are a few common reasons a transaction may not appear immediately:

Processing delay: Transactions can take up to 24–48 hours to be received and processed from the card network.
Card enrolled after the fact: Historical transactions that occurred before enrollment will not be synced retroactively.
Subaccount mismatch: Verify the transaction is associated with the correct subaccount ID.
Domestic debit / local network routing: Debit transactions routed via local networks such as Pulse (US) or Interac (CA) bypass the Visa/Mastercard rails entirely and will not appear in Astrada's feed. See Q16 for more on unsupported transaction types.
Transaction not on network rails: Some charges that appear on your bank statement never flow through a card network at all. Common examples include ACH payments (e.g., bill pay), bank-initiated fees (such as international transaction fees or annual fees), and certain recurring billing arrangements where the issuer charges the account directly. Astrada only receives data from Visa, Mastercard, and American Express — these transaction types will never appear in your feed, regardless of card enrollment status.
Network feed issue: In rare cases, a network-level delay or gap in feed delivery causes transactions to be missing. These are investigated with our network partners.
Visa VOP - Merchandise Return credits (TC 06): For individually enrolled Visa cards, standalone merchandise return credits (TC 06) are not supported by VOP and will not appear in Astrada. This is a known Visa network limitation. This means a refund that appears on your cardholder's bank statement may be absent from Astrada entirely. This is a known limitation of the VOP data product. Bulk enrollment or Astrada's Bank Data product can fill this gap.

Tip: If the transaction is more than 72 hours from posted date and still missing, open a support ticket and include the card ID, subaccount ID, transaction date, and amount.

Q2 — The transaction amount or record count in Astrada doesn't match my bank statement. What could cause this?

Note: Astrada may correlate multiple messages from the same merchant into a single transaction record, while your bank statement may display them as separate line items. This is expected behavior, not a discrepancy.

Discrepancies can occur for several reasons:

Partial clearing: Hotels, car rentals, and similar merchants authorize a hold amount that often differs from the final billed amount.
Multi-clearing transactions: A single authorization may result in multiple separate clearing messages - for example, an online order shipped in multiple shipments, or a hotel stay settled in stages. Astrada correlates these into a single transaction record where possible. If your bank statement shows separate line items for each clearing, this can cause an apparent record count mismatch.
Temporary Discrepancies:
- Tips or adjustments: Restaurants and service merchants can adjust the final amount after authorization.
- Gas station pre-authorization: Fuel merchants typically send an initial $1 authorization to verify the card, then settle the full fuel amount later. The $1 transaction is not a bug; it will be updated once the final settlement message arrives.

Tip: Always compare the cardholderBillingSettledAmount field (the bottom-line settled amount reflected on the cardholder's bank statement) to your bank statement, rather than cardholderBillingHoldAmount (the hold amount set at authorization, which may change as financial messages are processed). If you're seeing an unexpected amount, check the embedded message-level detail on the transaction to see whether multiple clearings are contributing to the total. If the discrepancy remains unexplained, contact support with the transaction ID.

Q3 — A transaction has been in 'pending' status for several days. When will it clear?

Most transactions clear within 1–3 business days of authorization. Some types take longer:

Hotel and car rental holds: Hotels in particular can take up to 30 days from initial authorization to final clearing — timing varies by merchant, as many batch their clearings rather than settling in real time. You may see an incremental authorization during this period as the merchant updates the hold amount — this is expected. Car rentals typically clear within 7–10 days after the rental period ends.
Refunds and reversals: Refund clearings can take 5–7 business days, depending on the issuing bank.
Network delays: Occasionally, a clearing message from the network is delayed. Astrada monitors for these and updates the transaction status when received.

Tip: If a transaction remains pending beyond 10 business days, open a ticket with the transaction ID so we can escalate to the card network.

Q4 — Transaction timestamps or dates look wrong — they don't match my bank statement.

Date discrepancies are usually caused by one of the following:

Timezone differences: Astrada stores all timestamps in UTC. Your bank statement may display times in your local timezone.
Authorization date: transactionOccurrenceDate reflects when the card was swiped. The settled date can differ by 1–3 days.
Refund timing: A refund's cleared date may appear before the settlement date in edge cases where the network sends the clearing message out of sequence. Refunds are usually shown through a transaction.updated event with FINL_ADVC being a negative amount.

Tip: Use transactionOccurrenceDate for when the transaction happened and for when it settled. Both are available on all transaction objects.

Q5 — I'm seeing duplicate transactions in the Astrada platform. How do I know which one is real?

Duplicate-looking transactions are uncommon but can occur in specific scenarios:

Re-presentment: A merchant may resubmit a previously declined or expired authorization, resulting in a second transaction for the same purchase. Note that one of these transactions is commonly voided, but the void may not arrive until a few days later.
Correction messages (FINL_ADVC): Some networks send a correction after the original clearing that can look like a duplicate. Check the transaction type field to distinguish.
Split transactions: A single purchase may be split by the merchant into multiple partial clearings.
Duplicate-looking cards with conflicting expiry dates: When a card is reissued with a new expiry but the same PAN, you may briefly see two entries. Confirm via the card ID and expiry fields.

Tip: Each transaction in Astrada has a unique transactionId. Compare IDs to determine if two entries are truly duplicates. If confirmed, report them to support with both IDs.

2. Card Enrollment & Connection

Q6 — I'm getting an error when trying to add or connect a card. What should I do?

Card connection errors can stem from several sources:

SCA / 3DS challenge failed (reqSCA): Astrada and our Network partner require Strong Customer Authentication. Ensure your integration handles the reqSCA response correctly and that the cardholder completes the 3DS challenge if prompted. If a card is stuck in reqSCA state, check the subscription status via GET /card-subscriptions/{id}. If retrying enrollment continues to fail, the issuing bank's authentication server may be rejecting the 3DS request - in this case, the cardholder should contact their issuer directly, as this cannot be resolved on the Astrada side alone
BIN not supported: Some card BINs are not eligible for enrollment (e.g., Consumer Debit cards, Consumer Prepaid cards, and closed-loop cards). See the product coverage docs and Q15 for a full list of supported and unsupported card types.
Card already enrolled: If the card was previously enrolled and not properly deactivated, a conflict may arise. Use GET /card-subscriptions/{id} to check the current subscription state.
Internal server error (500): Likely a transient platform issue. Retry after a few minutes; if it persists, open a support ticket.

Tip: Always include the cardID (if available) and the full error response body when opening a support ticket for enrollment failures — this significantly speeds up diagnosis.

Q7 — What is the difference between bulk enrollment and individual enrollment? Which should I use?

Astrada supports two enrollment modes depending on your use case:

Individual enrollment: The cardholder completes the connection flow one card at a time, typically via your UI using our SDK. Recommended when you need per-card cardholder consent and 3DS verification.
Bulk enrollment: A batch of cards are enrolled via file-based configuration or an API-driven process, without per-card cardholder interaction. Used by issuers or program managers managing cards on behalf of cardholders.

Key considerations for bulk enrollment:

Bulk enrollment applies to eligible Corporate and Commercial card programs. Business and Consumer card programs are usually not eligible. To check eligibility, use the GET /enrollment-methods endpoint. Consult the documentation or Astrada support if you have any questions.

Tip: Full bulk enrollment specs for Visa, Mastercard, and Amex are documented at docs.astrada.co/docs/network-bulk-enrollment.

Q8 — A card was enrolled, but transactions are still not coming through. What should I check?

If enrollment succeeded but transactions are missing, work through this checklist:

Subscription status: Confirm the subscription is active via GET /card-subscriptions/{id}. A status of pending or failed will block transaction delivery.
Subaccount active: Verify the subaccount associated with the card is active and correctly configured.
Webhook endpoint: Ensure your webhook endpoint is reachable and returning a 2xx response. Failed webhook deliveries are not retried indefinitely.
No transactions yet: If the card was just enrolled and no purchases have been made since enrollment, there will be no transactions. Historical transactions are not backfilled.
Card type limitation: If this is a virtual card issued under a parent card, see Q18 for details on virtual card visibility.

Tip: Full webhook documentation can be found at https://docs.astrada.co/docs/webhooks-1.

3. Webhooks & Notifications

Q9 — I'm not receiving webhook events. How do I troubleshoot this?

If your webhook endpoint is not receiving events, check the following:

Endpoint reachability: Your webhook URL must be publicly accessible and return an HTTP 200 response. Test it independently using curl or a webhook testing service.
Signature verification: If your endpoint rejects events due to failed signature verification, ensure you are using the correct webhook secret and following the HMAC-SHA256 validation process.
Event subscription: Confirm your account is subscribed to the event types you expect. Verify this via the API.
Response timeout: Astrada expects a response within 5 seconds. If your server is slow to respond, deliveries will be marked as failed.

Tip: If deliveries are being attempted but failing, check that your server is not timing out before returning a 200.

Q10 — What is the difference between the transaction.created and transaction.updated webhook events?

Astrada fires different events at different stages of a transaction's lifecycle:

transaction.created: Fired when a new transaction is first received from the network (e.g., at authorization). This is your earliest notification that a card was used.
transaction.updated: Fired when an existing transaction's state changes — for example, when it moves from pending to cleared, when the amount is adjusted at settlement, or when a refund or reversal is applied.

A single purchase will typically generate one transaction.created event at AUTH, followed by one or more transaction.updated events at clearing and settlement.

Note: Not all transactions progress beyond transaction.created. Declined authorizations, voided transactions, and inquiry/administrative transactions may not generate a transaction.updated.

Tip: Always use the latest transaction.updated to get the final, settled amount. The amount in transaction.created is the authorized amount, which may differ from the cleared amount.

Q11 — What is the expected sequence of transaction event types (AUTH_REQU, FINL_ADVC, etc.)?

Transactions typically flow through the following message sequence, though not every step is guaranteed:

AUTH_REQU: Authorization request — the initial message when the card is used.
AUTH_ADVC: Authorization advice — a confirmation or update to the authorization. Not always present.
FINL_ADVC: Final advice — a correction or update to the clearing message. May arrive after FINL_REQU.
A voided or refunded authorization can arrive as an AUTH_ADVC as a negative amount.

Tip: Your system should be built to handle messages arriving out of the expected sequence. Use transactionId to correlate all messages for the same purchase.

4. Refunds & Credits

Q12 — A refund or credit is showing as a positive charge instead of a credit. Is this a bug?

This is usually a display or integration issue rather than a data error. Here's what to check:

Transaction direction field: Refunds and credits will have a direction field set to CREDIT (vs. DEBIT for purchases). Ensure your application reads this field correctly when rendering amounts.
Reversal not yet reflected: If a reversal has been submitted but is not yet reflected in the transaction list, it may still be in transit from the network. Allow up to 24 hours.
Refund date: Refunds may post with a future or retroactive date relative to the original transaction. This is expected behavior from the card network.

Tip: If you believe the refund data itself is incorrect (wrong amount, wrong card), open a ticket and include the transactionId and cardId.

5. API & Integration

Q13 — I'm receiving 4xx Unauthorized errors when calling the Astrada API. What could be wrong?

4xx errors indicate an authentication problem. Check the following most common errors:

Token expiry: SDK tokens and access tokens have a limited lifetime. Ensure you are refreshing tokens before they expire and not caching them indefinitely.
Scope: In most cases, this won't be an issue; however, sometimes your account configuration wasn't passed through all the way on creation with the correct scopes. You will receive a specific 403 error requesting access to that scope when making a request.

Tip: If you are having issues when calling the Astrada API, reach out to your support Account Manager to reset your credentials.

Q14 — How do I create and manage subaccounts for testing? Can I delete them?

Subaccounts are the core organizational unit in Astrada for grouping cards and transactions.

Creating test subaccounts: Use the POST /subaccounts endpoint with your credentials to create a subaccount within your main production environment.
Deletion policy: We currently do not give our customers the ability to delete subaccounts via an API. If you want to delete a subaccount, please reach out to Astrada Support (Slack or email), and we can do this on your behalf.
Same card under multiple subaccounts: A card can technically be linked under multiple subaccounts, but this requires careful management to avoid data conflicts.

6. Supported Cards & Coverage

Q15 — Which cards and regions does Astrada support?

Astrada currently supports the following:

Networks: Visa and Mastercard open-loop Credit and Commercial Debit cards; and American Express Commercial cards.
Regions: United States, Canada, United Kingdom, and select countries in the European Union. Australia and New Zealand are also supported for bulk enrollment.

The following card types are not supported:

Consumer Prepaid and Consumer Debit cards
Closed-loop cards (gift cards, store cards)
Government-administered prepaid cards (including EBT)
Flexible Spending Account (FSA) and Health Savings Account (HSA) cards
Visa Buxx cards
SEB (Skandinaviska Enskilda Banken AB) Mastercard cards

Take a look at our docs for more information on our supported cards and overall product coverage.

Tip: If you're unsure whether a specific card BIN is eligible, you can use both our Enrollment Methods and BIN Lookup endpoints.

Q16 — Why are some of my debit card transactions not appearing in Astrada?

This is one of the most common missing-transaction root causes. There are two key scenarios:

Consumer debit cards: Consumer debit cards are not supported by Astrada. Only Commercial Debit cards (corporate/business debit) are eligible for enrollment.
Domestic debit network routing: Even for eligible debit cards, transactions processed through local/domestic debit networks — such as Pulse or Interlink in the US, or Interac in Canada — bypass the Visa and Mastercard payment systems entirely. These transactions will not appear in Astrada's feed, regardless of enrollment status. This is a network-level routing decision made by the issuer or merchant terminal.

There is currently no way for Astrada to intercept transactions that do not flow through the Visa or Mastercard systems.

Tip: If you believe you should be receiving debit transactions and aren't, please reach out to Astrada Support with your respective subaccountId and cardId.

Q17 — Does Astrada support American Express cards?

Yes. Astrada supports bulk enrollment for American Express business, corporate, and commercial card programs alongside its core Visa and Mastercard coverage — one platform for all transaction feeds, regardless of bank or network.

What's included with Amex today:

Bulk enrollment for all three Amex program types — no card-by-card setup required
Settled transaction data with 10+ structured fields per transaction, including merchant name, MCC, amounts, currencies, acquirer ID, geolocation, and more
Coverage across the US, Canada, UK, EU, Australia, and New Zealand

If your program includes Amex-issued corporate cards and you'd like to get started, contact your Astrada account manager to discuss eligibility and setup.

7. Virtual Cards

Q18 — Does Astrada support virtual cards? Why are some virtual card transactions missing?

Astrada has visibility over transactions made on virtual cards that are directly enrolled. However, virtual cards are commonly issued under a parent (physical) card. In those cases:

If the issuer processes virtual card transactions on the enrolled parent PAN: These transactions will appear in your data feed normally.
If the issuer processes transactions on the virtual PAN itself (which is not enrolled): These transactions may not appear in your feed. This is only an issue on individually enrolled cards.

There is no consistent way to determine whether a given transaction was processed on a physical or virtual card — this behavior is controlled by the issuer, not Astrada.

Payments made through indirect payment methods — such as Apple Pay or Google Pay — where you choose your Visa or Mastercard as a funding source but do not present your card token directly to the merchant, are also not supported.

Tip: If virtual card visibility is critical to your use case, discuss your issuer's processing behavior with your Astrada account manager before going live.

8. Transaction Data Visibility

Q19 — I have transactions in Astrada that don't appear on my bank statement (or vice versa). What are common causes?

Unmatched transactions between Astrada and bank statements usually fall into one of these categories:

Astrada has it, the bank doesn't (yet): Authorization transactions appear in Astrada immediately but may not post to your statement for 1–3 days. This is expected for pending transactions. Bank statements only show settled transactions and amounts.
Bank has it, Astrada doesn't: There are a variety of reasons why bank statements have settled transactions but Astrada does not. Some of the main reasons are related to network gaps, unique charges not captured on network rails, and the card not being enrolled with Astrada at the time of settlement.
Amount mismatch: See Q2 for common causes (FX conversion, tips, partial clearing, gas station pre-auth).
Orphaned clearing: Occasionally, a final clearing message arrives without a matching authorization. These represent real transactions — the AUTH was simply not received. A common reason for orphaned clearing is that the card was not enrolled at the time of the AUTH and only received the clearing/settlement.
Issuer-level fees: Fees charged by your issuer (e.g., international transaction fees) do not flow through the Visa or Mastercard payment systems and will not appear in Astrada.
Certain transaction types: Some transactions that credit an account directly aren't supplied back to Astrada via the network data product. An example of this could be a "merchandise return credit".

Tip: Please reach out to Astrada Support if you are receiving large amounts of unexpected orphaned clearings.

Q20 — How do I match Astrada transaction data to my bank or card statement?

Astrada has a unified bank + card data solution designed to give you complete transaction visibility in one place — no manual comparison required.

Bank account as the foundation: Connect your bank account through Astrada's API to establish the source of truth for what was actually charged. Under the hood this uses Plaid, but delivered through Astrada's normalized schema — the same format you already use for card data.
Card network data layered on top: Where real-time card network data is available, it's layered on top of bank data to give you richer transaction detail — merchant name, MCC, authorization context, and more.
Statement upload as an additional layer: For any remaining gaps, statement upload is available as a supplemental reconciliation input.
"Bank only" transactions surfaced: Transactions that don't flow through the card network — such as fees, transfers, and payments — are detected and surfaced so nothing falls through the cracks.

If you are interested in our Bank Data product and would like to learn more, please reach out to [email protected] or your account manager.

Tip: Bank data availability varies by region. If your program isn't eligible yet, you can still get ahead by listening to transaction.updated webhooks — this ensures your system always has the final settled state to compare against your bank statement.

9. Card Lifecycle

Q21 — What happens to a card's subscription when the card expires or is reissued?

Card reissuance and expiry are common lifecycle events that can affect transaction visibility:

Card expired or reissued with the same PAN, new expiry (single enrollment): Astrada treats each PAN + expiry combination as a distinct card fingerprint. When a cardholder re-enrolls the new card, a new subscription is created. The old subscription remains active and you may see two active subscriptions temporarily. You should deactivate the old subscription to avoid duplicate or missing transaction data.
Card expired or reissued with a new PAN:
- Bulk enrollment: The new card is received automatically from the network feed, and a new subscription is created; the old subscription is deactivated automatically. No action is needed on your end.
- Single enrollment: The new PAN is treated as an entirely new card. You must enroll it through the standard enrollment flow, and manually deactivate the old subscription via DELETE /card-subscriptions/{id}.
Card canceled/lost/stolen:
- Bulk enrollment: The network manages the removal of canceled/lost/stolen cards automatically. You cannot deactivate bulk-enrolled subscriptions via the API directly.
- Single enrollment: Deactivate the subscription via PATCH /card-subscriptions/{id} with {"state": "deactivated"} to stop transaction feed delivery. Historical transactions are retained.
Subscription does not auto-deactivate on expiry: Astrada does not immediately expire subscriptions when a card reaches its expiration date. Card data is fully purged after an additional 60-day inactivity period.

Tip: Build a process to audit your active subscriptions periodically and deactivate subscriptions for expired or cancelled cards to keep your card count accurate.

Q22 — A card is showing as enrolled, but the cardholder says their card number has changed. What should I do?

If a cardholder's card number (PAN) has changed — for example, due to fraud replacement — the old enrollment will no longer receive transactions for the new card. Here's what to do:

Deactivate the subscription for the old card via DELETE /card-subscriptions/{id}.
Initiate a new enrollment flow for the new card number. This may require the cardholder to complete 3DS verification again.
Do not attempt to re-use the old subscription ID for the new card — this will cause errors.
If you are on a bulk enrollment program, the new PAN should be submitted as a new entry in your next enrollment file.

Tip: Proactively communicate with cardholders during card replacement events so they know to re-link their card if prompted.

10. Testing

Q23 — How do I validate that my webhook endpoint is correctly receiving and processing events?

Endpoint readiness: Accept POST requests, return a 2xx response, and process events as they arrive in real time.
Event routing: Use webhook-event-type and a subaccountId to correctly route and handle events.
Signature verification: Validate each request using your signing secret to ensure authenticity.
Retry handling: Design for at-least-once delivery and deduplicate using event IDs.
Event ordering: Do not assume order — use timestamps, or fetch the latest state when needed.
Trigger a test event: In your test account, enroll a test card and make a simulated transaction to confirm the full event flow reaches your endpoint.

Tip: If you consistently see failed deliveries, check your server's timeout settings. Astrada expects a 200 response within 5 seconds — any processing of event data should happen asynchronously after acknowledgment.

Still need help?

Contact Astrada Support: [email protected]
Developer docs: docs.astrada.co

FAQ