Payment request callbacks
Sent to your callback URL whenever the status of a payment request changes. Payment requests created in the portal do not trigger these callbacks.
- Successful flow
- Expired
- Failed for other reasons
processing status when the customer clicks Proceed to payment, or immediately for a fixed payment request.processing status for each transaction, and the transaction is listed in the transactions block of the callback.paid status once the full amount is received and confirmed.Body
Payment request ID.
The foreign_id you provided when creating the payment request. Use it to map the callback to a customer or order in your system. An empty string if the payment request was created without one.
payment_request Payment request status.
processing: sent when the rate is fixed, that is, when the customer clicks Proceed to payment, or immediately for a fixed payment request. It's sent again each time a payment transaction is detected.paid: the expected amount was received and confirmed, or an underpayment was accepted. An accepted underpayment gets this status when the lifespan or rate lock period ends, whichever comes first.expired: the customer created no transactions during the lifespan or the rate lock periodfailed: the payment request was not fully paid in time, or the payment could not be processed. See the possible reasons.
After a payment request is paid, expired or failed, any subsequent incoming transaction triggers another callback with late_payment set to true for that transaction.
processing, paid, expired, failed The requested amount.
Unix time in seconds when the payment request's lifespan ends. If the rate lock ends earlier (valid_until), the customer must pay within the rate lock instead, and the payment request ends when the rate lock ends (with no transactions, it expires; with a partial payment, your underpayment handling rules apply).
Additional details about the status. Present only in some cases, described in Payment request statuses:
Underpayment accepted according to your payment handling rules(paid)The customer paid less than the requested amount. Based on your payment handling rules, the payment was not accepted(failed)The payment couldn't be processed because the transaction was invalid or couldn't be accepted(failed)Service is restricted for the payer. Payments from this payer cannot be processed(failed)
The customer's email, as entered on the payment page. If you provided end_user_email when creating the payment request, the email field on the payment page is prefilled with it, and the customer can change it.
The end_user_reference you provided when creating the payment request. Present only if it was provided.
Details of the address the customer pays to. Present once the customer has proceeded to payment.
Amounts the customer is expected to send and has sent. Present once the customer has proceeded to payment.
The amount received for the payment request, in the payment request currency, before the fees in fees are deducted. Present only for paid payment requests. Note:
- If the customer pays the processing fee (
user_fee_percentis100), this is the requested amount plus that fee, so you receive the requested amount after fees. - For an accepted underpayment, this is the amount actually paid, converted to the payment request currency.
- For an overpayment, this is the requested amount, and the extra is refunded to the customer (unless it's too small to refund), see Automatic refunds.
Payment transactions. Present once a transaction has been detected; before that, the field is left out rather than sent as an empty array. Invalid transactions are not included.
Fees charged for the payment request, deducted from currency_received. Present only for paid payment requests. The processing fee is listed even if the customer pays it.
Unix time in seconds when the rate was fixed. Present only after the rate is fixed.
Unix time in seconds until which the fixed rate is valid. Present only after the rate is fixed. Note:
- The rate is locked for at most 1 hour after
fixed_at, so for a payment request with a longer lifespan this is earlier thanexpires_at. In that case the customer must pay beforevalid_until. - At
valid_until, the payment request ends: it gets theexpiredstatus if the customer created no transactions, and a partial payment is handled according to your underpayment handling rules.