Skip to content
ElasticPay

Common Issues

Payment intent stuck in requires_payment_method

The card was not tokenized, or confirm was never called.

Check:

  • The widget’s onTokenize callback fired and the pm_xxx was sent to your server
  • The confirm endpoint was called with the payment_method field set
  • No errors were returned from the confirm call

Webhook not received

  1. Check the endpoint URL — verify the URL in Settings → Webhooks is correct and reachable from the internet (not localhost)
  2. Check account status — a suspended or deactivated account stops webhook delivery
  3. Check livemode — sandbox events only go to sandbox-mode endpoints; live events go to live-mode endpoints
  4. Check the delivery log — the webhook log in the dashboard shows all delivery attempts and HTTP response codes

refund_amount_exceeds_available error

The sum of all refund amounts for this payment intent would exceed the original payment amount. Check existing refunds before issuing another:

Terminal window
curl https://staging-api.elasticpay.co/api/v1/payment_intents/pi_0abc123/refunds \
  -H "Authorization: Bearer sk_sandbox_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

Sum the amount fields of all succeeded refunds. The remaining refundable amount is original_amount - total_refunded.

Customer on hold unexpectedly

A customer is on hold either because they were created with a payment method still to be collected (waiting for payment method), or because consecutive payment failures triggered recovery. Collecting a valid payment method clears the hold automatically — you no longer need to flip the status manually. To investigate:

  1. Open the customer detail page and check the Activity Log for recent status changes
  2. If they’re awaiting a method, use Collect Payment Details (or resend the email link) to capture one
  3. For a recovery hold, review the most recent failed payment intents for failure codes and use Open Recovery Setup Intent to send the customer a link to update their payment method

API key rejected (401)

Causes:

  • Key has been revoked — check Settings → API Keys for revocation date
  • Key has expired — check the expires_at field
  • Mode mismatch — sandbox key used against a live endpoint, or vice versa
  • Key copied with leading/trailing whitespace — verify the key value exactly

Plan not scheduling

  • Plan is in draft state — click Activate to begin scheduling. If the plan was created through the deferred payment-method flow, it activates automatically once the method is collected; a plan still in draft usually means the setup hasn’t succeeded yet
  • Customer is not active — a customer on hold or cancelled does not receive new scheduled payments
  • Plan is inactive or closed — reactivate or create a new plan
  • Start date is in the future — the scheduler creates intents up to 366 days ahead from today