30 docs tagged with "api"

With both IDs saved, you can charge that card whenever you need to — no customer, no browser, no 3DS.

A player is an Individual account. Create it, then run identity verification — a player must be verified before they can receive a bank payout or cash out.

The last step is creating the charge. You will need the customerid and the paymentmethod_id created in steps #2 and #3.

Once you have a token, the next step is to create a customer. You can create a new customer for every charge or you can reuse a customer created previously. This will depend on your use case.

Once a customer is created, you can create a payment method (card). You can create a payment method for every charge or you can reuse previously created payment methods.

Sessions should be created using your secret key as they should be created through your backend system to preserve the security.

In certain scenarios, you will need to provide a fingerprint ID generated by our JavaScript library.

A player can fund their wallet directly from a bank account. This is a pull: bank account → wallet. It is same-account — a pull funds the player's own wallet from the player's own bank. The credit settles asynchronously once the bank clears the debit.

Our API is designed to either generate IDs for new entities or accept IDs provided by your system.

This guide walks a casino-style platform through the full money lifecycle on Pathly: onboarding players, taking deposits, paying out winnings, and letting players cash out to their own bank account.

A charge refers to an attempt to process a payment using a customer's card. Charges may succeed, fail, or require additional actions, such as 3DS authentication. In some cases, charges may require additional time to produce a result, during which they will be marked as pending until confirmation is received from the acquiring entity.

A session represents an intention to charge a customer.

A card payment is one of two things, and the card networks treat them very differently.

Cashing out moves a player's wallet balance to their own bank account. This is a push: wallet → bank account. It is same-account — you can only cash out a wallet to that same account's bank. It settles asynchronously over the bank rail.

Bank-rail transfers (funding pulls and cash-out pushes) settle asynchronously, so subscribe to webhooks instead of polling. Add a webhook from your Developer Dashboard and subscribe it to the events you care about; you'll get the Signing secret used to verify each delivery.

Alongside the USD wallet, an account can hold a crypto wallet — a USDC balance on-chain (currently BASE-USDC, USDC on the Base network). Loading it works like a bank pull, but the rail is on-chain: get the deposit address, have the player send USDC to it, then watch for the credit.

POST /transfers is the same single endpoint used for fiat transfers — you get crypto behavior by setting currency to a crypto code (e.g. BASE-USDC) instead of USD. Two shapes are supported:

Every request (except this one) is authorized with a JWT in the Authorization header. Exchange your API key for a token at /jwt/token:

To make requests to our API, a token is required. To retrieve a token, you need to make a request to the /jwt/token endpoint as follows:

To hold a crypto wallet or receive fiat through a virtual account, a player completes a one-time crypto onboarding — an extension of the create & verify step. Two things must be true before crypto features activate:

Crediting a player — winnings, a deposit you collected by card, a bonus — is a wallet → wallet transfer from your merchant wallet to the player's wallet. It is internal: instant and final (born posted), no bank rail involved.

A virtual account is a fiat on-ramp for a player's crypto wallet: a set of real US bank coordinates (routing + account number) that the player can fund by ACH, wire, or FedNow. Money deposited is converted to USDC and credited to the player's crypto wallet — no card, no on-chain transfer.

This is the step everything else depends on. Two IDs, saved in your own database, against your own user record.

To monitor the outcomes of charges and sessions, you can subscribe to webhooks through our platform.

Players can deposit with a credit card. A charge collects funds into your merchant balance; you then credit the player's wallet with an internal transfer (see Pay out winnings — the same wallet→wallet mechanic).

The first payment must be customer-initiated. The customer is present, 3DS runs, and the card is stored — which is what makes every later merchant-initiated charge possible.