Follow-up on transactions
In legacy, DirectQuery requests allow you to get information about a transaction's status in two ways:
- Sending parameter PAYID/ORDERID only returns the global transaction status.
- Adding optional parameter PAYIDSUB returns a specific (temporary) status in the transaction's life cycle. For each (temporary) status, legacy creates individual PAYIDSUBs according to an incremental logic.
Direct replaces the PAYID/PAYIDSUB logic in favour of property payment.id
Our platform returns a separate, unique payment.id for every CreatePayment request and every maintenance operation (i.e. CapturePayment/RefundPayment/CancelPayment) you perform on an existing transaction. Hence, follow this payment.id logic when following-up on transactions proactively via GetPaymentDetails or processing our platform's transaction feedback via webhooks.
Legacy’s DirectQuery endpoint supports querying transactions based on the ORDERID, but the Direct endpoints GetPayment/GetPaymentDetails only accepts the aforementioned payment.id. This makes requesting a transaction's status more reliable: as the order.references.merchantReference can be reused for different orders, it might refer to more than one transaction in your database.
- Learn more about the payment.id logic in a dedicated chapter in our Webhooks guide.
- For CreateHostedCheckout requests via integration method Hosted Checkout Page, our platform returns a hostedCheckoutId instead of a payment.id. To follow-up on Hosted Checkout Page sessions, send a GetHostedCheckoutSession requests which accepts this hostedCheckoutId.