Order Billing Attempts

Ordergroove records a billing attempt every time it places an order. These records are also called placement responses. Each one captures what came back when the order was placed, so you can trace what happened to an order and reconcile it with your own systems.

To fetch them, use Retrieve placement responses. Results are sorted oldest first and paged with a cursor, as described in Cursor Pagination. The endpoint accepts Application API Scope only.

Normalized fields and raw payloads

Each billing attempt holds two kinds of data:

• Normalized fields that Ordergroove extracts, such as public_id, order, response_code, and response_message. They have the same names and formats on every platform.
• Raw payloads that hold what the upstream systems returned: response_payload and transaction_response.

Build your integration on the normalized fields, and keep the raw payloads for reconciliation and debugging.

response_code uses the codes from Recurring Order Placement: 000 is a success, and 140 is a declined payment.

Order placement response

response_payload holds the order placement response that Ordergroove received for the order. That’s the XML described in Recurring Order Placement. Ordergroove reads response_message and response_order_id from it.

Its structure comes from the system that placed the order, so it can vary by platform.

Transaction data

transaction_response holds the payment transaction that the platform reported for the order, as a transactionData XML element. Ordergroove moves this element out of response_payload, so it appears only here.

• Only Shopify merchants’ billing attempts include it. For other platforms it’s null.
• A Shopify billing attempt includes it only when the attempt has exactly one transaction. Otherwise it’s null.
• Its contents depend on the payment gateway and the payment method, such as a card or a digital wallet.

Working with the raw payloads

Because response_payload and transaction_response come from upstream systems, treat them as loosely structured text:

• Don’t validate them against a strict schema.
• Parse them defensively, with a fallback for when an element is missing or the format changes.
• Handle null, which you’ll see when an upstream system didn’t return the data.
• Use the normalized top-level fields for production logic wherever you can.