Charge a Saved Payment Method

Channels: Direct Methods: Card · BECS

Once a method is saved, you can charge it entirely server-side — the customer doesn’t need to be present. This is a merchant-initiated transaction (MIT): you initiate it under the agreement the customer made when the method was saved.

Create and confirm

# 1. Create the payment intent against the customer
curl -X POST https://api.elasticpay.co/api/v1/payment_intents \
  -H "Authorization: Bearer sk_sandbox_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{"amount": 4900, "currency": "AUD", "customer_id": "cus_0abc123def456"}'

# 2. Confirm with the saved payment method
curl -X POST https://api.elasticpay.co/api/v1/payment_intents/pi_0abc123/confirm \
  -H "Authorization: Bearer sk_sandbox_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{"payment_method": "pm_0xyz789abc123def456ghi012jkl"}'

Add an Idempotency-Key header so a retry can never double-charge — see Direct API Integration.

Rely on webhooks

For merchant-initiated charges, the webhook is the outcome — there’s no customer watching a spinner. Listen for payment_intent.succeeded and payment_intent.failed. BECS charges stay processing until the batch resolves and can dishonour days later.

What ElasticPay handles for you

Because the credential was established correctly at save time, each charge is automatically submitted with the right scheme evidence — stored-credential flags and the network transaction reference from the original authorisation for cards, the mandate for BECS. You don’t pass any of this; it’s threaded through from the save. Details: Stored Credentials & Recurring Charges.

Your responsibilities

Only charge within the agreement the customer accepted (amount, frequency, purpose)
Keep your own record of that agreement — it’s your evidence in a dispute
Handle failed outcomes with a sensible retry policy; don’t hammer a declined card or a dishonoured account