Discover products and required inputs
Read the current API documentation and OpenAPI schema before coding. Start with product kinds and catalog discovery, then read the selected product’s offers. Preserve product identifiers and use the documented fields for that exact offer.
Player ID, server and region requirements vary. Build the customer form from the actual required parameters, not from assumptions based on another game. If an offer is disabled or unavailable, do not accept a customer purchase based only on an old catalog snapshot.
Quote and authenticate on the server
Keep reseller API keys in your server environment. A browser or public repository is not a safe location for a purchasing credential. Your storefront should call its own server, which makes the authenticated supplier request.
Obtain the relevant quote before placing the order and confirm the account balance can cover it. Distinguish purchase cost from your own selling price. Current API documentation defines authentication and request fields; follow it rather than copying an unrelated supplier’s request example.
Use idempotency for safe retries
Bulk Epin documents an idempotency key for creating orders. Use one key for the same intended purchase so that a network retry is not interpreted as a different order. Do not create a new key just because a request timed out before you read its result.
Save the customer order reference together with the returned supplier order identifier. A timeout is ambiguous: the first request may have been accepted. Read the existing result before deciding whether a new purchase is necessary.
Track results and handle errors
Your customer interface should distinguish processing, delivery and failure. Read the order status through the documented API and provide the recorded delivery data only to the correct buyer. Do not assume webhook support if the current schema does not document it.
Observe the limit shown for your API key and handle rate-limit responses with their indicated delay. Test missing recipient fields, insufficient balance, repeated requests and unresolved orders using a small controlled integration. Keep reconciliation records and a support path for problems. A successful HTTP response alone is not evidence that in-game credit reached the recipient.