Where a payment stands (EAS-119)
Polled by the signer's page after the card is confirmed. When Stripe's webhook has not landed yet and the payment is still open, the PaymentIntent is read from Stripe, so a signer who has just paid is never left waiting on webhook delivery.
View as MarkdownPath Parameters
Response Body
application/json
application/json
application/json
application/json
application/json
curl -X GET "https://example.com/public/signing/string/fields/string/payment"{ "payment": { "status": "requires_payment", "paid": true, "amountMinor": 0, "currency": "string", "description": "string", "failureMessage": "string", "failureCode": "string" }}Start, or resume, the payment for a payment field (EAS-119)
Idempotent: a double click, a reload, or a retry after a declined card all land on the same PaymentIntent. The amount and currency are the field's own, snapshotted when the payment starts — nothing in the request can change them. Requires the same signing state as signingComplete (pending, before the deadline, this signer's turn, not yet signed or declined), and the field must be a payment field assigned to the caller. The response carries the client secret that Stripe.js confirms in the browser; whether the payment succeeded is never reported by the browser — it is learned from Stripe's webhook, or by reading the PaymentIntent server-side.
Stripe webhook (payments at signing)
Called by Stripe only — there is no session, and the request is authenticated by the Stripe-Signature header (t=<unix time>,v1=<hex HMAC-SHA256 of "<t>.<raw body>">) checked over the raw body, against every configured signing secret (the platform endpoint and the Connect endpoint have different ones), before the body is parsed. A delivery more than five minutes from now is refused. Each event is claimed by its id in the same transaction that applies it, so a redelivery changes nothing and a failed apply rolls the claim back. A payment's status only moves along the allowed transitions, and a terminal state (canceled, refunded) never moves again, so out-of-order delivery is harmless. An event about something this service does not know is acknowledged with 200 so Stripe stops retrying it. Only a failure a retry could fix (500, including an event that arrived before the row it depends on) asks for redelivery.