Begin with the customer record

The card API guidance starts with creating a customer and then selecting the product for issuance. Keep the relationship between your internal customer and the provider’s customer record clear. Your application should be able to determine which record belongs to a request without depending on a name copied from a screen.

This is also a permissions question. Not every operator or application component needs to create customers or issue cards. WATADCASH’s authentication documentation distinguishes customer and card permissions. Map those capabilities to the jobs in your application before choosing which credential each component will use.

Read the products available to the account

WATADCASH’s card API page points to card-products for the products available to the business account. That is a useful integration boundary: the available product list belongs to the account and service context, rather than to an assumption embedded forever in a checkout screen.

Display the current product information that your authorised integration is meant to use. If a product is unavailable, handle that condition explicitly instead of replacing it silently with another product. The customer’s choice, issue cost and intended use should remain connected throughout the request. Published consumer price tiers help explain products, but they are not a substitute for the actual account’s product response.

Track issuance as its own operation

After submitting an issuance request, retain its identifier and follow the result through the documented API or webhook process. Do not assume that creating a request means the card is already issued. Your internal state should distinguish the customer’s selection, the submitted instruction and the confirmed result.

That distinction helps customer support too. An operator can explain whether the request is awaiting a result or whether a card record has been created. It also prevents the interface from asking for a second issuance merely because the first response took longer than the user expected. Use the documented request and status mechanisms for the specific operation.

Keep funding separate from issuance

A newly issued card and a funded card are different states. WATADCASH’s documentation describes funding owned cards and refers to cards:fund permission and an eligible balance. Its public pricing also separates issuance from the money loaded onto a card.

Reflect that separation in the interface and internal records. Show the cost and status of issuance separately from the amount, fee and result of a funding request. If your product combines them into a guided journey, preserve the underlying references for both operations so a later question can be traced to the correct step.

Design for change without concealing it

Products, account eligibility and service conditions can change. A well-structured integration treats those changes as states to handle, not as unexpected strings that crash a successful-path demonstration. Keep business rules in a place where the team can review why a product is shown and which operation it permits.

WATADCASH’s public documentation gives developers a vocabulary for customers, products, card requests, permissions and funding. Use that vocabulary consistently in logs and support tools without exposing credentials or sensitive card data. The result is a clearer card service for the user and a more manageable operational system for the business.

Frequently asked questions

Should I hard-code the public card tiers as API product identifiers?

Use the available-products mechanism documented for the business account. Public tiers explain an offer, while an API product identifier belongs to the actual response and service context. Do not silently substitute a different product when availability changes.

Does submitting an issuance request mean the card is ready?

Keep submission and confirmed issuance as separate states. Retain the request identifier and follow the result using the documented API or webhook process. This makes delayed or repeated responses easier to handle correctly.

Why keep card funding in a separate record?

Funding has its own amount, charges, permissions and result. WATADCASH also distinguishes the issuance price from spending balance. Separate references allow support and reconciliation to identify which step needs attention.

Sources and verification

  1. WATADCASH card API overviewReviewed 2026-10-18
  2. WATADCASH card documentationReviewed 2026-10-18
  3. WATADCASH authentication permissionsReviewed 2026-10-18
  4. WATADCASH card pricingReviewed 2026-10-18