canonical: https://jentic.com/apis/hubspot.com/hubspot-crm-commerce-payments

# HubSpot Commerce Payments

The HubSpot Commerce Payments API exposes payment records inside HubSpot Commerce, representing captured payments that can be associated with contacts, deals, and invoices. It follows the standard CRM v3 object pattern with batch read, create, update, archive, search, and upsert operations against the commerce_payments object. Records carry properties such as amount, currency, payment method, processor, and reference id, providing a CRM-side ledger that mirrors the payments captured by your processor.

## For AI agents

Create, read, update, archive, search, and upsert HubSpot Commerce payment records, mirroring captured payments from a processor into the CRM ledger.

## Scope

Does not capture, refund, or settle payments at a processor - use only for managing HubSpot CRM payment records that mirror processor activity.

## Capabilities

- Record captured payments with amount, currency, method, and processor reference properties
- Batch upsert payments by an external processor reference id to avoid duplicates from retried webhooks
- Search payments by date, amount range, contact, or deal using filter groups
- Retrieve a payment record with associated contacts, deals, and invoices in one call
- Update payment properties (status, refund amount, processor metadata) after capture
- Archive payment records in batch when removing from active CRM views
- Page through all payment records for export or accounting reconciliation

## Use cases

### Processor Payment Mirror

Mirror captured payments from a processor like Stripe or Adyen into HubSpot so the CRM has a record of every payment alongside the contact and deal. Batch upsert by the processor's charge id ensures retried webhooks do not duplicate records, even at high volume.

Example prompt: POST 100 payment payloads to /crm/v3/objects/commerce_payments/batch/upsert with idProperty set to processor_charge_id and the deal association id.

### Refund Recording

When a refund is issued by the processor, update the corresponding payment record with the refund amount and date so the CRM ledger remains accurate. Search by processor charge id to find the right record before the update.

Example prompt: Search /crm/v3/objects/commerce_payments/search by processor_charge_id, then PATCH the matching record with hs_refund_amount and hs_refund_date.

### Revenue Reporting

Generate a CRM-side revenue report by searching commerce payments filtered by date and currency, summing hs_amount per deal owner. The search endpoint supports paging and property selection so the report is efficient.

Example prompt: Search /crm/v3/objects/commerce_payments/search with filterGroups on hs_payment_date in the last 30 days and currency = USD, returning hs_amount and ownerId.

### AI Agent Payment Reconciliation

An AI agent reconciles processor exports against HubSpot commerce payments daily, surfacing missing or mismatched records to a human reviewer. Jentic exposes the search and upsert operations with typed schemas, so the agent can detect gaps and create missing records without doc lookup.

Example prompt: Diff yesterday's processor charges against /crm/v3/objects/commerce_payments/search results; for each missing charge, upsert via /batch/upsert with idProperty = processor_charge_id.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /crm/v3/objects/commerce_payments/batch/create | Create payment records in batch |
| POST | /crm/v3/objects/commerce_payments/batch/upsert | Idempotent upsert by external id |
| POST | /crm/v3/objects/commerce_payments/batch/read | Read payments in batch by ID |
| POST | /crm/v3/objects/commerce_payments/batch/update | Update payment properties in batch |
| POST | /crm/v3/objects/commerce_payments/search | Search payments by filter groups |
| GET | /crm/v3/objects/commerce_payments/{commercePaymentId} | Retrieve a single payment |
| GET | /crm/v3/objects/commerce_payments | List payments with pagination |

## Key resources

- **commerce_payments** — Payment object with amount, currency, processor reference, and status properties.
- **Batch operations** — Batch read, create, update, upsert, and archive endpoints for processor sync.
- **Search** — Filter payments by date range, amount, currency, or associated objects.

## Why Jentic

- **Setup:** Wiring the HubSpot Commerce Payments API by hand means handling its OAuth 2.0 authorization-code flow or a private app token, targeting api.hubapi.com, and coding batch and search request shapes yourself. Through Jentic you install once, import HubSpot Commerce Payments from the API Directory, store the token once, and your agent calls it.
- **Permission scoping:** HubSpot gates this API with per-object OAuth scopes, so you grant only the payment-record scopes your agent needs and you choose which operations it may call: you can allow reading and searching payment records while leaving batch updates out of the allowed set unless you add them.
- **Credential handling:** Your HubSpot OAuth token or private app token is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'record a payment in HubSpot' or 'look up payment records', and Jentic returns the matching commerce payments operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Commerce Subscriptions** — Manages recurring subscription records that drive recurring payment events.
- **Invoices** — Tracks invoice records that payments are commonly applied to.
- **Stripe** — Stripe processes payments directly; HubSpot Commerce Payments is the CRM-side mirror.

## FAQ

### What authentication does the HubSpot Commerce Payments API use?

It supports OAuth 2.0 and HubSpot private app tokens. Through Jentic, tokens are stored encrypted in the vault and scoped tokens are injected at execution time, so the raw credential never enters the agent's context.

### Can I record refunds with the HubSpot Commerce Payments API?

Yes. Update the payment record with hs_refund_amount and hs_refund_date via PATCH /crm/v3/objects/commerce_payments/{commercePaymentId}. The Commerce Payments API does not initiate refunds at the processor - issue the refund through your processor first, then update the HubSpot record.

### What are the rate limits for the HubSpot Commerce Payments API?

Standard CRM v3 limits apply - 100 requests per 10 seconds for OAuth apps and 110 per 10 seconds for private apps. Use the batch upsert endpoint (up to 100 records per call) when mirroring high-volume processor activity.

### How do I upsert payments through Jentic?

Run the Jentic search "upsert hubspot commerce payment" to find POST /crm/v3/objects/commerce_payments/batch/upsert, load the schema, and execute with idProperty set to your processor's charge id. Jentic handles authentication.

### Is the HubSpot Commerce Payments API free?

Access requires HubSpot Commerce Hub. There is no per-call HubSpot fee on top of the Commerce subscription, but processor fees from your payment provider apply separately.

### Can I associate a payment with a deal and an invoice?

Yes - pass an associations array on create, or use the CRM Associations API afterwards, to link a single payment to a deal, invoice, and contact. The single-record GET supports an associations parameter to return linked IDs in one call.

### Can I limit what my agent is allowed to do with the HubSpot Commerce Payments API?

Yes. Jentic One is self-hosted, so you run it under your own rules and decide which Commerce Payments operations the agent may call. Because HubSpot gates this API with per-object OAuth scopes, you grant only the payment-record scopes the agent needs and choose the allowed set of operations: for example, you can permit reading and searching payment records while leaving batch create, update, and upsert out unless you explicitly add them. The HubSpot token stays with your own instance and is injected only at execution time, so the agent can call just the endpoints you approved.