Skip to main content

Take the First Payment

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.

You can take it in either of two ways, and both are already documented:

  • Create a Session — Pathly hosts the payment page. You redirect the customer, we collect the card and run 3DS, and you stay out of PCI scope. This is the simpler route and the one we recommend.
  • Create a 3DS charge — you create the customer and payment method yourself, then charge with a three_ds block and handle the acs_url redirect. Use this when you need control over the payment form.

Either way, the outcome is the same and it is the only thing this guide needs: a successful charge against a stored payment method, belonging to a customer.

What "successful" means here​

A 202 response is not a completed payment. It means the charge was accepted but its outcome is not yet known — either 3DS is required, or the processor settles asynchronously.

The first payment establishes the credential only once the charge reaches status: "succeeded". A charge sitting at pending unlocks nothing; charging as an MIT before it settles will be refused.

Confirm the outcome with the charge.updated or session.paid webhook, or by polling:

curl -i -X GET \
  https://sandbox-api.pathly.io/charges/8aa109e7-b4aa-4b8a-97fd-fd247bcc160f \
  -H 'Authorization: Bearer <YOUR_JWT_HERE>'

Do not treat the browser's return to your success_url as proof of payment. It is a navigation — it can be replayed, bookmarked, or never reached at all if the customer closes the tab.

Once the charge has succeeded, continue to Store the customer and payment method IDs.