REST API v2 listSubscriptions and getSubscription return payment_method_id: 0 for subscriptions with valid payment methods

[Mark_Ginat]

Issue: When calling the REST API v2 endpoints GET /v2/subscriptions (listSubscriptions) or GET /v2/subscriptions/{id} (getSubscription), the payment_method_id field returns 0 for subscriptions that have valid payment methods assigned in the legacy system.

Expected Behavior: The payment_method_id should return the REST API payment method ID that corresponds to the CreditCard assigned to the subscription.

Actual Behavior:

• REST API returns payment_method_id: 0

• XML-RPC query of RecurringOrder.CC1 returns the correct CreditCard table ID (e.g., 135076, 142485)

• The CreditCard table ID does NOT match the REST API payment_method_id (e.g., 30157)

Workaround Required:

1. Query RecurringOrder.CC1 via XML-RPC to get the legacy CreditCard ID

2. Query CreditCard table via XML-RPC to get Last4 digits

3. Match Last4 to REST API payment methods to find the correct payment_method_id

Impact:

• Breaks billing page card association displays

• Prevents accurate card-in-use detection for deletion protection

• Forces developers to maintain dual API implementations (REST + XML-RPC)

Request: Please populate payment_method_id correctly in the REST API v2 Subscription model, mapping the legacy RecurringOrder.CC1 to the corresponding REST payment method ID.

[OmarAlmonte]

@Mark_Ginat Thank you very much for the detailed and thorough review, we really appreciate you taking the time to document the issue so clearly, including the impact and workaround.

I’ll report this internally so the team can look into the issue. I’ll keep you posted and share updates as soon as I have more information.

Thanks again for flagging this.