Payment_method_id still not populated in /v2/subscriptions

@OmarAlmonte

The issue tracker says that the payment_method_id is listed as a known issue that was fixed on January 22nd. However, it’s still not fixed.

/v2/subscriptions
payment_method_id property is present, but incorrectly populated as 0.
The property should be populated with the correct value.

/v2/subscriptions/{$id}
payment_method_id property is present and populated.

/v1/subscriptions/
Works properly but uses the old XMLRPC credit card ID’s instead of the REST v2 payment_method_ids.
This makes the data incompatible with other data from the v2 API.

Request #1:
Check the /v/2/subscriptions endpoint to make sure it matches the. behavior on the /v2/subscriptions/{$id} endpoint

Request #2:
Use the specific endpoint(s) in the tracker instead of just the general resource.

PS:

I don’t know if it’s intentional, but the /v/2/subscriptions and /v/2/subscriptions/{$id} don’t return the same fields. Only the single record retrieval pulls the shipping address. That section is missing altogether from the list subscriptions endpoint.

Hi @David_Bullock,

Thanks for the detailed report. We’ll look into the payment_method_id issue on /v2/subscriptions and investigate the inconsistency.

For Request #2, good point. Since some bugs affect specific endpoints only, I’ll start listing the impacted endpoints directly in the tracker notes for clarity.

Appreciate the feedback.

@David_Bullock The issue with GET /subscriptions has been added to the tracker.

@David_Bullock This has now been fixed. Thank you for your patience!