> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://developer.ordergroove.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://developer.ordergroove.com/_mcp/server.

# 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](/reference/payment-attempt-data-api/placement-responses/retrieve-placement-responses). Results are sorted oldest first and paged with a cursor, as described in [Cursor Pagination](/api-reference/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](/lifecycle/order/recurring-placement#error-response-codes): `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](/lifecycle/order/recurring-placement#order-placement-response). 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.

> **Not a stable schema**
>
> The structure of `transaction_response` isn't guaranteed. It can change without notice when an upstream payment system changes.

---

## 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.