Elastic Path Payments API
When you [checkout](/docs/api/carts/checkout) a [cart](/docs/api/carts/cart-management), an unpaid [order](/docs/api/carts/orders) is returned. You can process the payment for the order though a payment gateway. :::note - You need to configure and enable a payment gateway before you can accept payments for orders. - Configure your store to use [Manual Gateway](/docs/api/payments/update-manual-gateway) to process payments if the order total is zero or the payment is through non-supported payment providers. - There are a number of actions that happen to your inventory when checking out and paying for an order. For more information, see [Inventory](/docs/api/pxm/inventory/inventories-introduction). - We recommend to wait until the payment confirmation process is fully completed before proceeding with any additional updates to the order. Making simultaneous updates to the same entity immediately after payment confirmation can lead to a race condition. To learn more information on handling parallel calls to API objects, see [Parallel Calls to API Objects](/guides/Getting-Started/api-contract#parallel-calls-to-api-objects). ::: ### Payment Methods Depending on the chosen gateway, you may or may not have access to capture funds immediately or authorize for later payment. To make a partial payment in Postman through any payment gateway, specify the desired payment amount in the amount field within the request body. To learn about Split Payments, see the [Split Payments](/docs/api/payments/payment-gateways-introduction#split-payments) section. #### Purchase The simplest method is purchase. The gateway attempts to charge the customer immediately, and the result of the attempt is returned. You can partially pay funds using purchase method. The gateway attempts to charge the customer immediately, and the payment status for an order shows `partially_paid`. When you Get an order, you can see the following fields in the `meta` object: - `balance_owing`: Specifies the outstanding funds required to complete an order. It considers all complete or pending transactions, including authorized, paid, and captured transactions. (`balance_owing` = order total - `authorized` amount - `paid` amount). - `paid`: Specifies the total amount of purchased or captured transactions. - `authorized`: Specifies the total amount of completed or pending authorized transactions for an order. #### Authorize You can `authorize` a payment so funds can later be captured when an item is dispatched or restocked. You can partially pay for an order using `authorize` payment method so that the order is `partially_authorized`. The transaction must be complete for the order status to be `partially_authorized`. For more information about order and payment statuses for split payments, see [Split Payments](/docs/api/payments/payment-gateways-introduction#split-payments). #### Capture After authorizing a transaction, you have to capture the authorized funds. :::note We recommend capturing payments several hours to days after the authorization to mitigate risks of fraud and chargebacks. When you sell digital goods that are delivered immediately, we recommend using a single purchase call instead of separate authorize and capture calls. ::: After the payment is `partially_authorized`, you must `capture` the authorized transaction later. Once you capture the authorized transactions, the order payment status will change to `partially_paid`. #### Refunds You can use either the Refund through Composable Commerce or use the Mark as Refunded capability, or a combination of both capabilities. For more information about refund for split payments, see [Refund a Payment](/docs/api/carts/refund-a-transaction). #### Refund through Composable Commerce You can start a full or partial refund to a supported payment provider directly from Commerce Manager or the API. When you start the refund process, the refund request is sent to the payment gateway. You no longer have to log on to your payment gateway's console to process the refund. When you process a refund, use the refund endpoint to pass the refund amount. If you don't pass an amount, the refund is processed as Mark as refunded. For more information, see the Mark as Refunded section. Each time a partial refund is triggered, the transaction.updated event is generated and updated with refunded.amount. The `order.updated` event is also triggered. The `order.refunded` event generates when the full amount is refunded. #### Mark as Refunded You can use your payment gateway's console to process a refund. Process the refund first in the payment gateway and then use the **Mark as Refunded** capability in Composable Commerce to complete the process. When an order is **Marked as refunded**, the payment status `order.payment.status` is set to `refunded`. In this case, the `order.updated`, `transaction.updated` and `order.refunded` events are generated.
Documentation
Specifications
openapi: 3.1.0
info:
version: 25.1126.6886238
x-version-timestamp: 2025-11-26 19:10:23+00:00
title: Addresses Introduction Account Addresses Payments API
description: 'The Addresses API allows you to organize account addresses. Addresses are a sub-resource of `account` resources, an account can have multiple addresses, such as home, work, and neighbour.
You can use an account address with either [client_credentials access token](/docs/api/authentication/create-an-access-token) or a combination of [implicit access token](/docs/api/authentication/create-an-access-token) and [Account Management authentication](/docs/api/accounts/post-v-2-account-members-tokens) token.
'
contact:
name: Elastic Path
url: https://www.elasticpath.com
email: support@elasticpath.com
license:
url: https://elasticpath.dev
name: MIT
servers:
- url: https://useast.api.elasticpath.com
description: US East
- url: https://euwest.api.elasticpath.com
description: EU West
security:
- BearerToken: []
tags:
- name: Payments
description: 'When you [checkout](/docs/api/carts/checkout) a [cart](/docs/api/carts/cart-management), an unpaid [order](/docs/api/carts/orders) is returned. You can process the payment for the order though a payment gateway.
:::note
- You need to configure and enable a payment gateway before you can accept payments for orders.
- Configure your store to use [Manual Gateway](/docs/api/payments/update-manual-gateway) to process payments if the order total is zero or the payment is through non-supported payment providers.
- There are a number of actions that happen to your inventory when checking out and paying for an order. For more information, see [Inventory](/docs/api/pxm/inventory/inventories-introduction).
- We recommend to wait until the payment confirmation process is fully completed before proceeding with any additional updates to the order. Making simultaneous updates to the same entity immediately after payment confirmation can lead to a race condition. To learn more information on handling parallel calls to API objects, see [Parallel Calls to API Objects](/guides/Getting-Started/api-contract#parallel-calls-to-api-objects).
:::
### Payment Methods
Depending on the chosen gateway, you may or may not have access to capture funds immediately or authorize for later payment.
To make a partial payment in Postman through any payment gateway, specify the desired payment amount in the amount field within the request body. To learn about Split Payments, see the [Split Payments](/docs/api/payments/payment-gateways-introduction#split-payments) section.
#### Purchase
The simplest method is purchase. The gateway attempts to charge the customer immediately, and the result of the attempt is returned.
You can partially pay funds using purchase method. The gateway attempts to charge the customer immediately, and the payment status for an order shows `partially_paid`.
When you Get an order, you can see the following fields in the `meta` object:
- `balance_owing`: Specifies the outstanding funds required to complete an order. It considers all complete or pending transactions, including authorized, paid, and captured transactions. (`balance_owing` = order total - `authorized` amount - `paid` amount).
- `paid`: Specifies the total amount of purchased or captured transactions.
- `authorized`: Specifies the total amount of completed or pending authorized transactions for an order.
#### Authorize
You can `authorize` a payment so funds can later be captured when an item is dispatched or restocked.
You can partially pay for an order using `authorize` payment method so that the order is `partially_authorized`. The transaction must be complete for the order status to be `partially_authorized`.
For more information about order and payment statuses for split payments, see [Split Payments](/docs/api/payments/payment-gateways-introduction#split-payments).
#### Capture
After authorizing a transaction, you have to capture the authorized funds.
:::note
We recommend capturing payments several hours to days after the authorization to mitigate risks of fraud and chargebacks. When you sell digital goods that are delivered immediately, we recommend using a single purchase call instead of separate authorize and capture calls.
:::
After the payment is `partially_authorized`, you must `capture` the authorized transaction later. Once you capture the authorized transactions, the order payment status will change to `partially_paid`.
#### Refunds
You can use either the Refund through Composable Commerce or use the Mark as Refunded capability, or a combination of both capabilities.
For more information about refund for split payments, see [Refund a Payment](/docs/api/carts/refund-a-transaction).
#### Refund through Composable Commerce
You can start a full or partial refund to a supported payment provider directly from Commerce Manager or the API. When you start the refund process, the refund request is sent to the payment gateway. You no longer have to log on to your payment gateway''s console to process the refund.
When you process a refund, use the refund endpoint to pass the refund amount. If you don''t pass an amount, the refund is processed as Mark as refunded. For more information, see the Mark as Refunded section.
Each time a partial refund is triggered, the transaction.updated event is generated and updated with refunded.amount. The `order.updated` event is also triggered. The `order.refunded` event generates when the full amount is refunded.
#### Mark as Refunded
You can use your payment gateway''s console to process a refund. Process the refund first in the payment gateway and then use the **Mark as Refunded** capability in Composable Commerce to complete the process.
When an order is **Marked as refunded**, the payment status `order.payment.status` is set to `refunded`. In this case, the `order.updated`, `transaction.updated` and `order.refunded` events are generated.
'
paths:
/v2/carts/{cartID}/payments:
parameters: []
post:
tags:
- Payments
summary: Create Stripe Payment Intent for a Cart
description: 'The Cart Payment Intent feature enables the creation of a Stripe Payment Intent specifically tied to a shopping cart and its subsequent order. This allows Payment Intent users to track payment details from the cart stage and seamlessly maintain consistency in payment information throughout the order stage. Using these features, you can create Payment Intents for their carts, update Payment Intents with final cart details, and synchronize Payment Intents from Stripe to Commerce.
:::note
- Typically, in Commerce, inventory is allocated at the time of payment initiation after an order is created. However, in the case of Cart Payment Intent, information about the payment is received only upon synchronizing the order from Stripe to Commerce. This may happen after the payment is completed. Therefore, there might be a delay between the payment made and allocation, increasing the chance of paying for items that are not in stock.
- There are certain fields you can choose to set up when [creating a payment intent](https://stripe.com/docs/api/payment_intents/create). However, if you decide to update a payment intent, the available options may not be the same as those allowed while creating a payment intent. See [updating a payment intent](https://stripe.com/docs/api/payment_intents/update).
:::
The following steps outline the workflow associated with the Payment Intent:
1. [Add items to cart](/docs/api/carts/manage-carts#add-custom-item-to-cart).
1. [Create a Payment Intent for the cart](/docs/api/carts/create-cart-payment-intent). The Payment Intent is created in Stripe, reflecting the cart and transaction details, including currency, amounts, payment type, and any optional Stripe details. The Payment Intent ID is generated and linked to the cart.
1. [Update a Payment Intent](/docs/carts-orders/update-cart-payment-intent). This step is optional but becomes necessary when there are changes in the cart details at the time of payment. It ensures the Payment Intent accurately reflects the current cart details when processing the payments on the front end.
1. [Checkout the cart](/docs/api/carts/checkout). An unpaid order is created, and the Payment Intent ID is linked to the order.
1. [Confirm the order](/docs/carts-orders/confirm-an-order). This is important because after checkout, it is essential to confirm the Payment Intent and synchronize it with Commerce. This results in a corresponding transaction and change in order statuses in Commerce. Additionally, the Payment Intent ID is removed from the order once it is linked via the transaction.
### Best Practices
We recommend you follow these practices to maintain consistency and accuracy when using Cart Payment Intent.
- After checkout, we recommend clearing the shopping cart. You can achieve this using a [Delete a cart](/docs/api/carts/delete-a-cart) endpoint or [Update a cart](/docs/api/carts/update-a-cart) to remove the Payment Intent ID. This helps to avoid potential issues where subsequent checkouts for the same cart might unintentionally use the previous Stripe Payment Intent ID.
- If it is not reasonable to clear the cart immediately after checkout due to several subsequent, duplicate checkouts to the same cart, ensure that you only synchronize the Payment Intent when finalizing the order. Each order confirmation is unaware of the others, and syncing Payment Intent IDs for each confirmation can lead to duplicate transactions in Commerce. In other words, if you synchronize Payment Intents for earlier versions of a repeated checkout, you''ll end up with multiple orders from the same cart, each having transactions linked to the same Payment Intent.
- To pay the entire amount at once, use the [Update Cart Payment Intent](/docs/carts-orders/update-cart-payment-intent) endpoint to update the Stripe Payment Intent with the final cart details when preparing to take the payment. Doing so, ensures that the Payment Intent accurately reflects the current cart details when processing payments on the front end. We do not recommend calling the [Update Cart Payment Intent](/docs/carts-orders/update-cart-payment-intent) for each individual change in the cart, as this can lead to more requests and may slow down the front-end performance.
'
operationId: createCartPaymentIntent
parameters:
- name: cartID
in: path
required: true
style: simple
schema:
type: string
description: The universally unique identifier of the cart for which you want to create a payment intent.
requestBody:
required: false
content:
application/json:
schema:
$ref: '#/components/schemas/ElasticPathPaymentsPoweredByStripePayment'
examples:
Create Stripe Payment Intent for a Cart:
value:
data:
gateway: elastic_path_payments_stripe
method: purchase
options:
automatic_payment_methods:
enabled: true
receipt_email: john@example.com
Create Stripe Payment Intent for a Cart Using Specific Payment Methods:
value:
data:
gateway: elastic_path_payments_stripe
method: purchase
payment_method_types:
- affirm
- card
- link
options:
receipt_email: john@example.com
responses:
'201':
description: Payment Intent created successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/CartEntityResponse'
deprecated: false
/v2/orders/{orderID}/payments:
parameters: []
post:
tags:
- Payments
summary: Payments
description: 'Depending on the payment gateway, you may have access to different transaction types such as capturing funds immediately or authorizing them for later. For more information, see [Payments](/docs/api/carts/payments).
The following types of payment methods are available depending on the payment gateway:
- `purchase`: This is the simplest method. The gateway attempts to charge the customer immediately.
- `authorize`: This method authorizes a payment so that funds can be captured later, for example, when an item is dispatched or restocked.
- `purchase_setup`: This method prepares the system for a purchase by verifying payment details without actually charging the customer. For example, a customer adds items to their cart and proceeds to checkout. Before finalizing the purchase, the system runs `purchase_setup` to confirm all payment details, but no funds are transferred until the customer confirms the order.
- `authorize_setup`: This method prepares the system for an authorization-only transaction. This process holds the necessary funds but does not transfer them, ensuring that the customer has sufficient balance for the transaction. It sets up the conditions for a future capture of the authorized funds. For example, a customer places a pre-order for a product that will ship in two weeks. The merchant uses `authorize_setup` to prepare for the payment authorization. This holds the customer''s funds to ensure they can cover the purchase but waits to capture the payment until the product ships. This ensures that payment is secured but not collected prematurely.
:::note
Split payments can be performed using any methods for any gateway.
- You can partially pay funds using `purchase` method. The gateway attempts to charge the customer immediately, and the payment status for an order will show `partially_paid`
- You can partially pay for an order using `authorize` method where the order will be marked as `partially_authorized`. The transaction must be completed for the order status to be `partially_authorized`.
- A `purchase_setup` method allows verification of payment details for partial payments without transferring funds until the customer confirms the full order.
- An `authorize_setup` method can be used to hold a partial amount of the total funds, ensuring the customer has enough balance for a future capture.
Until a payment is made neither `purchase_setup` nor `authorize_setup` affects the payment statuses, and the order remains unpaid. For more information about order and payment statuses for split payments, see [Split payments](/docs/api/payments/payment-gateways-introduction#split-payments).
:::
'
operationId: paymentSetup
parameters:
- name: orderID
in: path
description: The Universally Unique Identifier (UUID) of the order you want to pay for.
required: true
style: simple
schema:
type: string
requestBody:
description: ''
content:
application/json:
schema:
allOf:
- $ref: '#/components/schemas/PaymentsRequest'
required: false
responses:
'200':
description: OK
content:
application/json:
schema:
$ref: '#/components/schemas/TransactionEntityResponse'
'400':
description: Bad Request
content:
application/json:
schema:
$ref: '#/components/schemas/Response.ErrorResponse'
examples:
default:
summary: Required field missing
value:
errors:
- detail: Request could not be processed
status: '400'
title: Bad Request
'409':
description: Conflict
content:
application/json:
schema:
$ref: '#/components/schemas/Response.ErrorResponse'
'422':
description: Unprocessable Entity
content:
application/json:
schema:
$ref: '#/components/schemas/Response.ErrorResponse'
deprecated: false
/v2/orders/{orderID}/transactions/{transactionID}/confirm:
parameters: []
post:
tags:
- Payments
summary: Confirm Payment
description: 'Confirm Payment serves as a mechanism to synchronize transaction information from the third-party payment provider back to our system. This ensures that Composable Commerce accurately reflects the values from the payment provider.
### Handling 3D Secure Validations for Stripe Payments
For Stripe Payments requiring 3D Secure validation, the transaction response will include the `client_parameters` object, which provides credentials to support validation of these payment requests on the payment provider''s side. We recommend using the Stripe''s client libraries to manage these 3D Secure validations. Once the validation succeeds, proceed with a confirmation request to sync the validated transaction into Composable Commerce and continue with the payment process.
'
operationId: confirmPayment
parameters:
- name: orderID
in: path
description: The unique identifier of the order.
required: true
style: simple
schema:
type: string
- name: transactionID
in: path
description: The unique identifier of the transaction.
required: true
style: simple
schema:
type: string
requestBody:
description: ''
content:
application/json:
schema:
allOf:
- $ref: '#/components/schemas/OrdersTransactionsConfirmRequest'
responses:
'200':
description: ''
headers: {}
content:
application/json:
schema:
$ref: '#/components/schemas/TransactionEntityResponse'
'400':
description: Bad Request
content:
application/json:
schema:
$ref: '#/components/schemas/Response.ErrorResponse'
examples:
default:
summary: Required field missing
value:
errors:
- detail: Request could not be processed
status: '400'
title: Bad Request
deprecated: false
/v2/orders/{orderID}/transactions/{transactionID}/capture:
parameters: []
post:
tags:
- Payments
summary: Capture a Transaction
description: Use this endpoint to capture a previously authorized payment. In this step, you can also pass in a custom reference, such as the payment reference from your chosen gateway.
operationId: captureATransaction
parameters:
- name: orderID
in: path
description: The UUID of the order.
required: true
style: simple
schema:
type: string
- name: transactionID
in: path
description: The UUID of the transaction to capture.
required: true
style: simple
schema:
type: string
requestBody:
description: ''
content:
application/json:
schema:
allOf:
- $ref: '#/components/schemas/OrdersTransactionsCaptureRequest'
required: false
responses:
'200':
description: ''
headers: {}
content:
application/json:
schema:
$ref: '#/components/schemas/TransactionEntityResponse'
'400':
description: Bad Request
content:
application/json:
schema:
$ref: '#/components/schemas/Response.ErrorResponse'
examples:
default:
summary: Required field missing
value:
errors:
- detail: Request could not be processed
status: '400'
title: Bad Request
deprecated: false
/v2/orders/{orderID}/transactions/{transactionID}/refund:
parameters: []
post:
tags:
- Payments
summary: Refund a Transaction
description: 'There are two ways to refund; through your payment gateway and mark it refunded in Commerce Manager, or directly through Commerce Manager or API.
* Mark as Refunded: You can manually mark a transaction as refunded. Before you can mark the order as refunded, you need to handle the actual refund on your side with your payment provider. Mark as Refunded is a full refund made to the transaction.
* Refund through Composable Commerce: You can process a full or partial refund to a supported payment provider directly from Commerce Manager or API by providing the refund amount. When you start the refund process, the request is directly sent to the payment gateway.
:::caution
If you use manual gateway for partial or full refund, you need to handle the actual refund on your side with your payment provider.
:::
'
operationId: refundATransaction
parameters:
- name: orderID
in: path
description: The UUID of the order.
required: true
style: simple
schema:
type: string
- name: transactionID
in: path
description: The UUID of the transaction you want to refund.
required: true
style: simple
schema:
type: string
requestBody:
description: ''
content:
application/json:
schema:
allOf:
- $ref: '#/components/schemas/OrdersTransactionsRefundRequest'
required: false
responses:
'200':
description: ''
headers: {}
content:
application/json:
schema:
$ref: '#/components/schemas/TransactionEntityResponse'
'400':
description: Bad Request
content:
application/json:
schema:
$ref: '#/components/schemas/Response.ErrorResponse'
'422':
description: Unprocessable Entity
content:
application/json:
schema:
$ref: '#/components/schemas/Response.ErrorResponse'
examples:
default:
summary: Validation error
value: "{\n \"errors\": [\n {\n \"detail\": \"Transaction cannot be refunded in its current state\",\n \"status\": \"422\",\n \"title\": \"Unprocessable Entity\"\n }\n ]\n}\n"
deprecated: false
/v2/orders/{orderID}/transactions:
parameters: []
get:
tags:
- Payments
summary: Get Order Transactions
description: Get order transactions
operationId: getOrderTransactions
parameters:
- name: orderID
in: path
description: The unique identifier of the order.
required: true
style: simple
schema:
type: string
responses:
'200':
description: ''
headers: {}
content:
application/json:
schema:
$ref: '#/components/schemas/TransactionListResponse'
'400':
description: Bad Request
content:
application/json:
schema:
$ref: '#/components/schemas/Response.ErrorResponse'
examples:
default:
summary: Required field missing
value: "{\n \"errors\": [\n {\n \"detail\": \"Request could not be processed\",\n \"status\": \"400\",\n \"title\": \"Bad Request\"\n }\n ]\n}\n"
deprecated: false
/v2/orders/{orderID}/transactions/{transactionID}:
parameters: []
get:
tags:
- Payments
summary: Get a Transaction
description: Retrieves a transaction
operationId: getATransaction
parameters:
- name: orderID
in: path
description: The unique identifier of the order that you require transactions for.
required: true
style: simple
schema:
type: string
- name: transactionID
in: path
description: The unique identifier of the transaction.
required: true
style: simple
schema:
type: string
responses:
'200':
description: ''
headers: {}
content:
application/json:
schema:
allOf:
- $ref: '#/components/schemas/Response.Data'
- type: object
properties:
data:
$ref: '#/components/schemas/TransactionResponse'
deprecated: false
/v2/orders/{orderID}/transactions/{transactionID}/cancel:
parameters: []
post:
tags:
- Payments
summary: Cancel a Transaction
description: 'Use this endpoint to cancel or void a pending or authorized transaction. The transaction can be canceled or voided when it is in `pending` and `completed` statuses.
:::caution
This endpoint works only for Stripe and PayPal and does not work for manual gateway.
:::
'
operationId: cancelATransaction
parameters:
- name: orderID
in: path
description: The unique identifier of the order.
required: true
style: simple
schema:
type: string
- name: transactionID
in: path
description: The unique identifier of the transaction to be canceled or voided.
required: true
style: simple
schema:
type: string
requestBody:
description: ''
content:
application/json:
schema:
allOf:
- $ref: '#/components/schemas/OrdersTransactionsCancelRequest'
required: false
responses:
'200':
description: ''
headers: {}
content:
application/json:
schema:
allOf:
- $ref: '#/components/schemas/TransactionEntityResponse'
'400':
description: Bad Request
content:
application/json:
schema:
$ref: '#/components/schemas/Response.ErrorResponse'
deprecated: false
components:
schemas:
TransactionListResponse:
type: object
properties:
data:
type: array
items:
$ref: '#/components/schemas/TransactionResponse'
required:
- data
CustomDiscountResponse:
title: CustomDiscountResponse
type: object
properties:
type:
description: Specifies the type of the resource. Always `custom_discount`.
type: string
const: custom_discount
id:
description: Specifies the UUID of the custom discount.
type: string
format: uuid
examples:
- 662461ad-ddcb-4dbd-8ed7-ade9aa63b5f9
external_id:
description: Specifies an external id for the custom discount.
type: string
examples:
- custom-discount-external-id
discount_engine:
description: 'Specifies from where the custom discount is applied.
'
type: string
examples:
- Custom Discount Engine
amount:
description: The amount of the custom discount.
$ref: '#/components/schemas/FormattedPriceData'
description:
description: Specifies a description for the custom discount.
type: string
examples:
- Custom discount description
discount_code:
description: Specifies the discount code used for the custom discount.
type: string
examples:
- cart-custom-promo-code
relationships:
description: Relationships to other resources like cart items
type: object
properties:
item:
type: object
properties:
data:
type: object
properties:
id:
type: string
format: uuid
description: The cart item ID this discount is related to
type:
type: string
enum:
- cart_item
- custom_item
CartResponse:
title: CartResponse
allOf:
- $ref: '#/components/schemas/BaseCartResponse'
- type: object
properties:
type:
description: The type of object being returned.
type: string
const: cart
Data.PaymentObject:
oneOf:
- $ref: '#/components/schemas/Data.AdyenPayment'
- $ref: '#/components/schemas/Data.AuthorizeNetPayment'
- $ref: '#/components/schemas/Data.BraintreePayment'
- $ref: '#/components/schemas/Data.CardConnectPayment'
- $ref: '#/components/schemas/Data.CyberSourcePayment'
- $ref: '#/components/schemas/ElasticPathPaymentsPoweredByStripePayment'
- $ref: '#/components/schemas/Data.ManualPayment'
- $ref: '#/components/schemas/Data.PayPalExpressCheckoutPayment'
- $ref: '#/components/schemas/Data.StripePayment'
- $ref: '#/components/schemas/Data.StripePaymentIntentsPayment'
FormattedPriceData:
title: FormattedPriceData
type: object
properties:
amount:
description: The raw total.
type: number
examples:
- 10000
currency:
description: The currency set for this amount.
type: string
examples:
- USD
formatted:
description: The formatted total based on the amount and currency.
type: string
examples:
- $10.00
Response.ErrorItem:
type: object
required:
- status
- title
properties:
title:
type: string
description: A brief summary of the error.
examples:
- Bad Request
status:
type:
- string
- integer
description: The HTTP response code of the error.
examples:
- '400'
detail:
type: string
description: Optional additional detail about the error.
examples:
- The field 'name' is required
source:
type: string
description: The field or location that caused the validation error. For JSON schema validation errors, this contains the JSON path to the invalid field (e.g., 'data.name', 'request', 'data.items[0].quantity').
meta:
type: object
description: Additional metadata associated with the error. May include arbitrary keys.
properties:
id:
type: string
description: The resource id associated with the error
ids:
type: array
items:
type: string
description: The resource ids associated with the error
item_ids:
type: array
items:
type: string
description: The cart_item ids associated with the error
shipping_group_id:
type: string
description: The shipping group id associated with the error
shipping_group_ids:
type: array
items:
type: string
description: The shipping group ids associated with the error
cart_id:
type: string
de
# --- truncated at 32 KB (62 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/elastic-path/refs/heads/main/openapi/elastic-path-payments-api-openapi.yml