cuprice_plan_id is 0, and the chosen features come with the checkout link. The custom plan card sends them like this:
Step 1: Price the selection on your server
The query string can be edited by the buyer, so send the selection back to Cuprice and use the answer:payload.features, not the names from the query string. Cuprice only lists features that exist in the project there, so a made-up name cannot sneak in.
Step 2: Keep the features with the payment
Savefeatures and amount on a pending order in your database and pass the order ID to your payment provider. Provider metadata fields are often too small for a long feature list.
Step 3: Save on the customer after payment
When your provider confirms the payment, copy the order’s features onto the customer. From there, checks work the same as for regular plans.Feature fields
Each entry inpayload.features for a custom plan has:
string
required
Feature name, for example “Team seats”. Custom plan features carry no
id (it is null).string
The feature type, for example
Limits or Usage Basednumber
The amount the buyer chose for a limit or usage-based feature, or the feature’s default amount.
null for on/off features.object
model (flat, limits or usage_based), unitPrice and subtotal for this featureCustom plans cannot be reported to Cuprice with Report Subscription Event, because that endpoint needs a Cuprice plan ID.
