> ## Documentation Index
> Fetch the complete documentation index at: https://docs.thedecard.com/llms.txt
> Use this file to discover all available pages before exploring further.

# FAQ

> The questions that come up most before and after launch: onboarding turnaround, resubmission after KYB/KYC rejection, uniqueness rules, card count caps, obtaining PANs, custodians, physical upgrades, choosing a funding mode and webhook fallbacks.

## 📄 Guide

These questions come from partners' most frequent enquiries during integration and operations. If yours is not here, contact the DCS team.

## Frequently asked questions

**Q1. How long does company onboarding take after submission?**

Complete KYB first, then call the endpoint to create the company. Onboarding is asynchronous: the endpoint returns only the application ID and `PENDING` synchronously. The result arrives as `ORGANIZATION_CREATED` / `ORGANIZATION_REJECTED`, and can also be polled by application ID. Acceptance is not approval — after receiving the application ID, do not issue cards straight away; once the company is created, follow the flow in the [Quickstart](../getting-started/quickstart).

**Q2. Can a rejected KYB / KYC be submitted again?**

Yes. Use resubmit under the same application ID, with corrections. It is allowed only while the current state is `REJECTED`; an in-flight or already-approved application returns a state conflict.

**Q3. Can emails and phone numbers be reused?**

No. Within one partner, company emails, employee emails, employee phone numbers and company registration numbers are all unique, and once taken they are not released even after a rejection. To change them, go through resubmit or the employee-update endpoint — do not reapply under a new external ID.

**Q4. Does renaming an employee re-trigger KYC?**

Yes. If a KYC is already in flight the call returns `KYC_IN_REVIEW`; retry after the result lands.

**Q5. How many cards can a company / employee hold?**

There are caps at two levels — per company and per holder — counting live cards and in-flight applications together; exceeding them returns `CARD_LIMIT_EXCEEDED`. Confirm the exact numbers with your support contact during onboarding.

**Q6. When do I get the card number? Can I get the full PAN?**

Query as soon as card creation succeeds (`CARD_CREATED`), but regular endpoints return only the first 6 and last 4 digits. For the full PAN / CVV2 / expiry, use the retrieve-secure-card endpoint — which requires PCI DSS certification.

**Q7. Why must a company card name a custodian?**

The custodian is the card's contact person and must be an active employee of the company. They are contacted when something is wrong with the card, and complete verification when a purchase triggers a 3DS challenge.

**Q8. After a virtual-to-physical upgrade, do my card IDs and targets change?**

No. The upgrade keeps the same number: `cardId`, PAN, expiry and CVV2 all stay the same — it is the same card object throughout. After activation, the physical card takes effect.

**Q9. Company pool or dedicated balance — which should a customer pick?**

For "many cards spending together, centralised bookkeeping", the company pool; for "one budget per card, stop when it runs out, isolated books", dedicated-balance cards.

**Q10. How do I learn about a low balance first?**

Configure the company's low-balance alert: a threshold per currency; crossing it pushes `LOW_BALANCE` (and an email, if a mailbox is configured); once per day until the balance recovers.

**Q11. How do I get the final result of an asynchronous call?**

Use both channels: webhooks as the primary, and the query endpoints — polled by application ID or your external identifier — as the fallback. Anything that returns `PENDING` / `PROCESSING` synchronously goes into your local to-do queue for scheduled polling; a fund transfer returning `PROCESSING` must be confirmed by polling.

**Q12. What if a webhook never arrives?**

The retry window is only about 3 minutes (at most 4 deliveries); if your receiver is down longer, events will be missed — always back yourself up with the query endpoints. Events carry no ordering guarantee; go by `webhookId` (a monotonically increasing snowflake ID) plus the resource's current state.

**Q13. How do I debug a signature failure?**

Locate by error code. The most common cause is a wrongly assembled string to sign: GET uses the raw query string (empty string if none), POST uses the request body verbatim (do not re-serialise), concatenated as `apiKey + timestamp + nonce + payload`, with the HMAC in lowercase hex. Webhook verification is a separate scheme (sort field names lexicographically first, then compact-serialise).

## Next steps

* The full signing and webhook specification: [Quickstart](../getting-started/quickstart)
* The per-domain how-to guides: [Managing companies](../how-to-use/managing-companies), [Managing cards](../how-to-use/managing-cards)