We are attempting to use the Checkout API with subscriptions… I’m submitting the following request to create a subscribe link:
{
“idempotencyKey”: “df308c4f-340a-4547-af61-5d1d2252195c”,
“checkoutOptions”: {
“subscriptionPlanId”: “4ERVJKTANLQ7U5XUPBTT3MRH”,
“redirectUrl”: “”
},
“prePopulatedData”: {
“buyerEmail”: “”
},
“order”: {
“locationId”: “LVC1DH6QGF7B1”,
“customerId”: “test_patient”
}
}
We are getting back the following response from the sandbox:
{
“id”: “IDZD6XD3WS27Q624”,
“version”: 1,
“orderId”: “31bnoK4NOYYsX751AbmGO8Wyva4F”,
“checkoutOptions”: {
“subscriptionPlanId”: “4ERVJKTANLQ7U5XUPBTT3MRH”,
“redirectUrl”: “”
},
“prePopulatedData”: {
“buyerEmail”: “”
},
“url”: “Checkout API Sandbox Testing Panel”,
“createdAt”: “2022-08-05T19:07:06Z”
}
However, when I use the link, and click on the “Preview Link” button, we are just getting a blank page… even though the subscription plan ID is valid for the sandbox:
Please advise…
P.S. I tried in production as well, and got exactly the same results.
Hey there! 
It looks like there’s some issues with the fields you’re setting in your request. You’ll need to specify price_money, which is the initial phase price of the subscription plan. You can find a walkthrough on how to do this on our developer documentation. I recommend referencing the CreatePaymentLink example request if you just want to see what fields need to be set.
That said, I’m surprised that your request even succeeded if it generated an erroneous payment link. I’ll let the team know about this and see if there can be stricter validation for this endpoint. Thanks for bringing it to our attention!
Ok, from what I read when I sent the request without quick_pay… it said quick_pay or order could be provided. at the root, order just looked like an easier route to take, since I didn’t have the subscription details handy. I assumed the back-end would pull the details from the subscription plan.
ok, adding quick_pay instead of order, it’s now working…
However, I’m trying to test out a subscription with a free 7-day trial, then a monthly cost after 7 days. This isn’t clear on the payment page now, it just says $0 … it’s really not clear to the end user that it’s $X after 7 days.
Please advise… Thanks
I figured out I need to pass in the last phase of the subscription when creating the payment link…
One last question I promise, I think…
I’d like to be able to pass in an ID for the user when creating the payment link for a subscription. Additionally, I’d like to receive this user ID on my end when subscription events come in through the webhooks. Does anything exist like that currently?
Thanks,
Richard
The user ID you want to pass in is your own internal user ID, right? You can use the payment_note field to pass this information in. It’ll be attached to the Payment object, which you can retrieve from the webhook.
I’m not seeing any paymentId in the subscription.created or subscription.updated events… i guessing a payment isn’t triggered until their card is actually charged because of the free trial I have in my subscription plan. I need to associate our user record with the subscription as soon as the web-hook gets invoked for one of those events above.
Any other suggestions?
For now, I know subscriptionId is passed back to the redirectUrl… so I’m going to pull that and update our user account. It’s just a bit of a race condition, since this may not get set before the web-hook is invoked.
P.S. I’m going to try putting our ID into the source field.
Gotcha, I understand why that isn’t ideal. I don’t have any other ideas myself, but I’ll check with the team to see if they have any other suggestions! 
I appreciate it… it’s pretty standard for subscription systems to allow a “user ID” to be inserted into the subscription, so when the web-hook is invoked with a success or when the subscription is cancelled, it makes it pretty easy to deactivate the user our in our systems.
Thanks,
Richard
Just to add, we have a work-around for now… basically, we had to add some parameters to the redirectUrl, then create the association between the user ID and the subscription ID, then redirect them onto the manage page for the subscription.
It’s not idea to do it this way, since if any part of this front-end process fails, we’ll end up with a person getting subscribed, but their user ID not getting associated with their subscription which would be an issue for us to deal with on the customer service side of things… something we’d obviously like to avoid
Sorry for the delay getting back to you. I talked with the team, and you should be able to use an order to create a subscription payment link. However, you will need to add line_items so that the initial phase of the subscription plan can be paid. For example:
{
"idempotencyKey": "{{idempotency_key}}",
"checkoutOptions": {
"subscriptionPlanId": "{{subscription_id}}"
},
"order": {
"location_id": "{{location_id}}",
"line_items": [
{
"name": "Subscription Fee",
"quantity": "1",
"base_price_money": {
"amount": 100,
"currency": "USD"
}
}
]
}
}
The team’s working on adding in some stricter validation so that the endpoint will actually return an error instead of responding with a non-functional checkout. Thanks for flagging this!
