Orders and payment collection work together to handle purchases in the Connect API. Orders track what a customer is buying, while payments — collected through your own provider or via managed payment sessions — fulfill the payment requirement before the order can be submitted.Documentation Index
Fetch the complete documentation index at: https://docs.telnesstech.com/llms.txt
Use this file to discover all available pages before exploring further.
Core Concept
Every order has requirements that must be met before submission:- requiresPayment: Whether the order needs payment before it can be fulfilled
- requiresPaymentProfile: Whether a stored payment method is needed for future billing
- requiresSigning: Whether the order requires a digital signature
NOT_REQUIRED, OPTIONAL, or REQUIRED. Check these after calculating the price to determine the correct submission flow.
Zero-total orders may not require payment at all. Always check the order
requirements rather than assuming payment is needed.
Quick Path
Check Requirements
Inspect the order requirements to determine if payment, a payment profile, or signing is needed.
Choosing a Payment Approach
The Connect API gives you full flexibility in how you collect payments. You can use your own payment infrastructure or leverage managed payment sessions depending on your needs.Your Own Provider (Recommended)
Collect payment through your existing payment stack (Stripe, Adyen, Braintree, etc.) and pass the reference when submitting the order. Full control over the checkout experience, payment methods, and provider relationship.
Hosted Payment Page
Use a managed payment session with
hosted: true to get a provider-hosted checkout URL. Redirect customers to a pre-built payment page with no frontend payment UI to build.Embedded Payment Widget
Use a managed payment session with
hosted: false to get provider credentials for rendering a payment form directly in your UI using the provider’s SDK.When to Use Each Approach
| Approach | Best for |
|---|---|
| Your own provider | Teams with an existing payment infrastructure who want full control over the payment experience, provider selection, and checkout flow |
| Hosted payment page | Quick integrations where you want a turnkey payment UI without building frontend payment components |
| Embedded widget | Teams who want a managed payment backend but need to customize the payment UI within their application |
Most integrations use the external payment approach because it lets you keep your
existing payment provider, maintain a single payment relationship, and have
complete control over the customer checkout experience.
1. Create an Order and Add Line Items
Create an order for a customer and include the products they want to purchase.2. Calculate the Price
Calculate taxes and totals before collecting payment.3. Check Order Requirements
After calculating the price, inspect the order to determine what is needed before submission.4. Collect Payment
Once you know the order requires payment, choose one of the following approaches.Option A: Your Own Payment Provider (Recommended)
Collect payment through your existing payment provider (Stripe, Adyen, Braintree, or any other provider). This approach gives you full control over the checkout experience and lets you use your existing payment infrastructure without any additional dependencies. After collecting payment on your side, submit the order with anexternalPayment reference:
externalPayment object accepts:
| Field | Required | Description |
|---|---|---|
reference | Yes | The payment reference or transaction ID from your provider |
receiptDescription | No | A human-readable description of the payment |
receiptUrl | No | A URL to the payment receipt or confirmation page |
When using external payments, you are responsible for collecting the correct
amount and handling refunds through your payment provider.
Option B: Hosted Payment Page
If you prefer a managed payment flow, create a payment session withhosted: true to get a checkout URL. Redirect the customer to the provider-hosted payment page.
returnUrl. Poll the payment session to confirm the status before submitting the order.
Option C: Embedded Payment Widget
Create a payment session withhosted: false (or omit the field) to get provider credentials for rendering a payment form directly in your UI.
Zero-Total Orders with Payment Profile
For orders with a zero total that still require a stored payment method (e.g., trial subscriptions), submit with a payment profile session ID instead.Order States
| State | Description |
|---|---|
PENDING | Order is in cart state, can be modified |
PENDING_PAYMENT | Order is locked and awaiting payment completion |
SUBMITTED | Order has been submitted for processing |
PENDING_APPROVAL | Order is pending approval |
PROCESSING | Order is being fulfilled |
COMPLETED | Order has been successfully fulfilled |
CANCELLED | Order was cancelled before completion |
EXPIRED | Order expired due to inactivity |
FAILED | Order fulfillment failed |
Payment Session Statuses
| Status | Description |
|---|---|
PENDING | Session created, awaiting customer payment |
REQUIRES_ACTION | Additional action needed from the customer (e.g., 3D Secure) |
COMPLETED | Payment successfully collected |
FAILED | Payment failed |
Requirements Reference
When you retrieve an order after calculating the price, therequirements object tells you what is needed before submission.
| Requirement | Values | Description |
|---|---|---|
requiresPayment | NOT_REQUIRED, OPTIONAL, REQUIRED | Whether payment must be collected |
requiresPaymentProfile | NOT_REQUIRED, OPTIONAL, REQUIRED | Whether a stored payment method is needed |
requiresSigning | NOT_REQUIRED, OPTIONAL, REQUIRED | Whether a digital signature is needed |
Next Steps
Orders
Full order management API reference
Payment Sessions
Managed payment session creation and management
Payment Profiles
Stored payment methods for recurring billing
Webhooks
Set up notifications for order and payment events