What This Update Actually Is
HubSpot is standardizing the PaymentMethod enum across its Revenue Hub APIs. Right now, the Payment Links API uses its own local enum that no other Revenue Hub API surface shares. That local enum includes a value called CARD.
Starting July 27, 2026, CARD becomes CREDIT_OR_DEBIT_CARD. The new value is the same shared type used across HubSpot's other Revenue Hub API surfaces. No other enum values are affected by this change.
There's no feature flag. There's no opt-in window. The change deploys automatically. If your integration is still sending or parsing CARD on July 27, it breaks.
Why HubSpot Shipped This
Inconsistent enums across APIs create real problems for the humans building on top of them. When one API surface uses CARD and every other Revenue Hub surface uses something different, developers have to write translation logic just to make their own tools talk to each other. That's extra code, extra maintenance, and extra room for bugs.
HubSpot's goal here is a single shared type across all Revenue Hub APIs. One standard, no translation layer, less cognitive overhead. It's a housekeeping move, not a feature launch, but it matters for anyone running a custom integration against Commerce Hub or the Payment Links endpoint.
The internal frustration this resolves is real: developers who've built quote-to-cash or payment processing workflows have to mentally map mismatched values across API surfaces. Standardizing the enum removes that friction permanently.
How to Use It Step by Step
The fix is straightforward if you audit before July 27. Here's the exact process:
- Search your codebase for every instance of the string "CARD" in any file that touches the HubSpot Payment Links API. Check request builders, response parsers, switch statements, conditional logic, and test fixtures.
- Replace each instance of "CARD" with "CREDIT_OR_DEBIT_CARD" in your paymentMethod field handling. Double-check both outbound request payloads and inbound response parsing.
- Update any switch/case or if-else blocks that match on the paymentMethod value. A missed case branch is where silent failures hide.
- Update your test fixtures and mock API responses. Tests that use the old CARD value will pass locally but mask a broken integration in production.
- Deploy your updated integration before July 27. If you're using a staging environment, test the updated paymentMethod value against the HubSpot sandbox to confirm the new enum is accepted.
- After July 27, monitor your payment-related error logs. Confirm that no 400-level errors are appearing on the paymentMethod field before you close out the task.
What It Touches in Your HubSpot Strategy
On the surface, this looks like a one-line rename. But it ripples into more places than most teams expect on first read.
Custom payment integrations are the obvious target. If your team built a connector between HubSpot and a billing system, ERP, or data warehouse using the Payment Links API, the paymentMethod field is almost certainly in your payload. That's your first audit point.
Key Takeaway
Any automation, webhook listener, or Zap that reads HubSpot payment data and routes on payment method type must be updated. CARD will no longer be a valid response value after July 27.
Reporting pipelines are the less obvious risk. If you're pulling payment data into a BI tool or a custom HubSpot report and filtering by paymentMethod, your CARD filter will return zero results after the change. That looks like a sudden drop in card payments. It's actually a broken filter.
Workflow branches inside HubSpot that evaluate paymentMethod values also need a look. If you've built automation logic that branches on payment type, confirm whether those branches reference the raw API value or a mapped property. Update accordingly.
If you're already managing HubSpot pipeline logic through the API, this is a good moment to audit your full API surface coverage. The public API for CRM pipeline rules shipped recently and adds another layer of programmatic control that intersects with Revenue Hub data. Make sure your team's API strategy accounts for both.
Key Takeaway
Standardized enums across Revenue Hub APIs mean future integrations will be faster to build and easier to maintain. This breaking change is short-term pain for long-term consistency.
Commerce Hub is seeing a wave of structural improvements right now. The auto-association update for Contracts and Orders is another recent change that affects how revenue objects connect to activity history. If you're building a comprehensive RevOps data layer, these two updates are worth sequencing together in your audit.
Who Should Care Most
This update is narrow but the stakes are high for the humans it affects. Here's who needs to act before July 27:
- Developers maintaining a custom HubSpot Payment Links integration: update your paymentMethod handling now, before the deadline.
- RevOps and operations leaders who own HubSpot's Commerce Hub setup: loop in your developer or agency partner immediately if you're using payment links programmatically.
- Agencies and HubSpot partners managing portals with payment automation: audit every client portal that uses the Payment Links API and communicate the change proactively.
- Data and BI teams pulling payment records from HubSpot into external dashboards: check every filter, segment, and downstream report that references payment method.
If your portal uses HubSpot's native payment links but doesn't have a custom API integration, you don't need to do anything. The UI-level payment experience is not affected. This is an API-only change.
George's Take
I've seen this pattern play out in portals more times than I can count: a "small" API change slips through because it doesn't have a UI component, nobody's monitoring it directly, and the first sign something broke is a revenue report that looks completely wrong. This particular change is exactly that kind of quiet risk. It's not a new feature. It's not exciting. But if you've got any custom payment automation running in your portal and you miss the July 27 deadline, you're looking at broken integrations and data gaps right at the point in your revenue stack where you can least afford them. Audit your code now, not the morning of the 27th.
“The updates that don't make the headlines are often the ones that hurt the most. A one-line API rename can break your entire payment reporting stack if nobody's paying attention.”
If you're not sure whether your HubSpot setup uses the Payment Links API directly or through a third-party connector, that uncertainty is itself a signal. It's worth a conversation.
The Sidekick team works with portals at every stage of API maturity, from first-time Commerce Hub setups to complex multi-system Revenue Hub integrations. If you want a second set of eyes on your payment integration before the July 27 deadline, or if you want to build out a more resilient API layer going forward (including the kind of pipeline rule automation covered in our public API for CRM pipeline rules breakdown), book a strategy call and let's map it out together.
Frequently Asked Questions
What is the HubSpot Payment Links API breaking change on July 27, 2026?
HubSpot is renaming the CARD value in the PaymentMethod enum to CREDIT_OR_DEBIT_CARD. This is a breaking change in the Payment Links API. Any integration that sends or parses the CARD value in the paymentMethod field will stop working correctly after July 27 unless updated. No opt-in is required; the change deploys automatically.
Do I need to update my HubSpot portal if I use payment links without a custom API integration?
No. If you use HubSpot's native payment link functionality through the UI and don't have a custom API integration, you don't need to do anything. This breaking change only affects integrations that programmatically read or write the paymentMethod field via the Payment Links API.
What code do I need to change for the CARD to CREDIT_OR_DEBIT_CARD update?
Search your codebase for every reference to "CARD" in files that interact with the HubSpot Payment Links API. Update request builders, response parsers, switch statements, conditional branches, and test fixtures. Replace "CARD" with "CREDIT_OR_DEBIT_CARD" wherever the paymentMethod field is handled. Deploy the changes before July 27, 2026.
Why did HubSpot change the CARD enum value in the Payment Links API?
HubSpot is standardizing the PaymentMethod enum across all Revenue Hub APIs. The Payment Links API previously used a local enum not shared with other Revenue Hub surfaces. Aligning on a single shared type reduces inconsistency and removes the need for developers to maintain translation logic between different API surfaces.
Will this change affect HubSpot payment reports or dashboards?
Yes, if your reports or BI tools filter payment data by the paymentMethod field value. Any filter, segment, or dashboard that references "CARD" will return zero results after July 27 because the value no longer exists. Update those filters to use CREDIT_OR_DEBIT_CARD before the change deploys to avoid gaps in your revenue reporting.
Is there an opt-in or feature flag for the CREDIT_OR_DEBIT_CARD enum change?
No. There's no opt-in, no feature flag, and no grace period after deployment. The change is automatic and applies to all HubSpot tiers on July 27, 2026. All integrations using the Payment Links API must be updated before that date to avoid broken functionality.
