A wallet denominated in a currency now drives the same automation as one denominated in credits. Auto top-up fires on an amount threshold. Wallet balance workflows accept an amount threshold too. The trigger reports both the balance and the threshold in the wallet’s own unit. Wallet grants are now issued per pricing period, not per invoice. A repeated on-demand charge grants its credits per line. A forward-billed grant lands in the wallet of the customer the subscription is for. Seat assignments are manageable from Desk. Calendar billing anchors a multi-month period on the schedule start.
A clearer error when pass-through pricing meets the wrong meter value
Pass-through pricing bills the amount carried on the event, so it can only be configured against a meter value of type AMOUNT. Any other meter value was rejected with “not compatible with non AMOUNT usage”, which named neither the pricing type that refused nor what it needed. The message now reads PASS_THROUGH pricing requires an AMOUNT meter value.
Adding a pricing group no longer fails on the pricing category order
Adding a pricing group to a pricing plan version could introduce a product category the version did not have yet. If a custom order had been set through “Change pricing order”, this failed with display_order is configured on 3 of the 4 pricing categories, it must be configured on all of them or on none of them. Desk now assigns a display order to the new category itself, so an explicit order stays complete. See Pricing groups.
default_seats_value on a pricing item config was accepted as an amount, which is not a seat count anything could multiply by, and is now rejected with seats value must be a number. A seat count configured as zero bills no seat line at all, as a zero count already did.Auto top-up and balance workflows for wallets denominated in a currency
A CREDIT wallet type funded with an amount keeps its ledger in a currency rather than in a credit type. Invoice usage that takes the open balance below the configured threshold now schedules the auto top-up, and wallet.wallet_balance.threshold.amount is accepted on a workflow definition for such a wallet type.
There is no conversion between a credit type and a currency, so a threshold is only valid in the wallet’s own unit. An amount threshold on a wallet type denominated in credits is rejected with amount threshold not allowed for CREDITS wallets. A credits threshold on a wallet type denominated in an amount is rejected with credits threshold not allowed for AMOUNT credit wallets. An amount threshold’s currency has to match the wallet type’s credit.amount_grant.default_currency. LESS_THAN remains the only comparator. See Wallet top-ups and Credit types & wallets.
In Desk, the threshold field now follows the unit of the selected wallet type. It resets when you switch to a wallet type in the other unit, so a figure entered in credits is never resubmitted as an amount. The workflow summary now states the amount with its currency instead of a credit unit name.
A wallet grant is issued per pricing period, not per invoice
A wallet_grants rule on a pricing item config was issued once per invoice. Now each pricing period produces its own grant, with its own validity window. This matters when the config’s pricing_period is shorter than its billing_period: on a plan billed twice a year, a monthly expiry_policy now behaves as configured, instead of covering the whole six-month invoice. See Credits in pricing plans.
A repeated on-demand item grants its credits per line Charging on demand accepts the same pricing item more than once in one request. Both lines carry the invoice date and land in the same invoice group. So an item at 100 USD granting a fixed 500 credits, charged twice, takes 200 USD and deposited 1000 credits.
A forward-billed grant lands in the wallet of the customer the subscription is for Under forward billing the invoice is addressed to the parent, but the subscription belongs to the child. A wallet grant from such a subscription now resolves to the subscription’s own customer, not the parent. The same holds for forwarded usage: it draws from the subscription’s own customer balance. See Parent-child relationships.
Manage seat assignments from Desk
Seat assignments record which processing-only child customer occupies which seat, and they are what per-seat credits are attributed against. Until now they existed only on the API. From the context menu of a per-seat pricing item on a subscription, beside “Show seats history”, the new panel lists the seats assigned under that parent for that seat type with occupant, window and status, and assigns a child to a seat, ends an assignment, reopens it or deletes it. Only processing-only children of that parent are offered, and each action respects its SEAT_ASSIGNMENT permission. See Seat-based pricing and Seat-based credits.
open_invoice_amount and a paid_invoice_amount above its own total. A payment pending refund or reversal still counts as paid until the refund settles; a settled refund no longer does.payment_status is persisted when an invoice is marked as paid by hand. The write that settled the invoice updated the paid flag and the open amount but left the payment status at its previous value, so the invoice read back as paid while still reporting NOT_PAID or PARTIALLY_PAID. See Invoice payment status.A rate-limited request is retried instead of failing the payment
A burst of invoice payments can take the payment provider over its rate limit. A 429 response was not in the retry set. It surfaced as an error, even though nothing had actually gone wrong: the payment action was marked ERROR and each item raised an alert. 429 is now retried. The fixed half-second wait between retries was also replaced with exponential backoff and jitter, as the provider documents. See Dunning and payment retries.
Breaking: a wallet balance trigger reports the balance in the wallet’s own unit
open_balance and threshold on the wallet_balance trigger were a bare credits object, which cannot express the balance of a wallet denominated in a currency. Both are now a container carrying credits and amount, of which exactly one is populated, decided by the wallet type:
A consumer reading open_balance.quantity has to move to open_balance.credits.quantity. The send-email action is unaffected: wallet_balance and wallet_balance_threshold are rendered figures either way, and credit_unit_name carries the currency code when the wallet is denominated in an amount. See Workflow triggers.
Pick the billing currency when adding pricing to a subscription Adding a pricing directly on a subscription pre-selected the platform’s default currency and gave no way to change it, so a subscription billed in another currency had to be built elsewhere. The currency is still pre-selected, from the subscription, and is now editable. See Custom pricing.
Event reprocessing moved next to the usage it explains The reprocessing log is now a tab under Usage metering rather than a page of its own, so the events and the reprocessing they went through are read in one place.
DONE are hidden on an invoice, since the report they produced is listed already and showed as a duplicate beside it.Credit grants on a pricing item can now scale with the number of seats purchased. Seat occupancy is tracked as its own resource through the new seat assignments API, and a wallet can show which customer’s usage reserved which part of its balance. Also: a credit-amount wallet’s tax category is now always set, workflow emails include the template variables the legacy integration used to inject, and draft workflows can be deleted.
You can now leave product items unpriced One product can back several plans that each charge for a different subset of its items: leave the rest unpriced, and events matching those items produce no charge on that plan. The API always allowed a pricing to skip product items of its product; Desk was what enforced pricing every item. Now you can remove a product item from a pricing on a pricing plan version, a rate card version, or a schedule pricing, which makes filtered product items usable in practice. An unpriced item still renders as an “Unpriced” card with an “Add pricing” action, so leaving one out stays visible rather than silent.
Credit grants that scale with seats
A wallet-grant rule on a pricing item config declares what its quantity is derived from through a new source field, so a plan sold per seat can hand out credits per seat without a separate rule per customer. FIXED is the default and grants the quantity exactly as configured, which is what every existing rule does. SEAT_POOL multiplies the configured quantity by the applicable purchased seat count and grants the result into the shared customer wallet as a single grant per rule per billing period, never one grant per seat. The seat count comes from seats_values on the pricing plan schedule for that pricing item, falling back to default_seats_value on the item config when the schedule sets none.
SEAT_POOL is only valid on a PER_SEAT pricing item, since seat counts are scoped to a pricing item rather than to the schedule as a whole; the API rejects it elsewhere with a validation error on wallet_grants. Issued grants carry the same source read-only, so a grant that was seat-scaled is identifiable after the fact. The enum also declares PER_SEAT, for credits owned by an individual seat rather than pooled; it is not implemented yet and is rejected with PER_SEAT is not supported yet. See Seat-based credits for the full configuration, including how the seat count is resolved and how seats added mid-period are topped up.
In Desk, the grant source is configured on the wallet grant in a pricing, and a seat-scaled grant shows the seat count it resolved against.
See whose usage reserved a wallet balance
A shared credit pool spent by several child customers reported one reserved figure with no way to see where it came from. The wallet balance status can now return customer_details, a breakdown of the reserved balance per customer, requested with include_customer_details on the balance call. Each entry carries customer_id and that customer’s share of the reserved balance. The split is recorded when an invoice is built or refreshed, so it reflects the usage that has actually been drafted against the wallet.
A credit-amount wallet type’s tax category is enforced
A CREDIT wallet type funded with an amount carries a tax category and a default currency. The tax category was required at create time but only stored and returned: nothing read it, so it constrained nothing. It is now the declared spending scope of the wallet. Money funded under one tax category must not become spendable under another, so the tax category and the default currency can no longer be changed once wallets exist for that wallet type, and neither can be removed once set. Changing either on a wallet type that has no wallets yet is still allowed, and an attempt to change one under existing wallets is rejected with a validation error on credit.amount_grant.tax_category or credit.amount_grant.default_currency. See Credit types and wallets.
Seat assignments: record which customer occupies a seat
seats_values on a pricing plan schedule records how many seats are paid for, but nothing recorded which child customer occupies one. A processing-only child was linked to its parent only through parent_resource_ids, so there was no way to exclude a child from being counted as a seat, to distinguish seat types, or to compare occupied seats against paid seats. Seat assignment is now an explicit resource at /v1/seat-assignments, with create, list, get, update and delete:
Occupancy is keyed on the PER_SEAT product item, which is the seat type, rather than on the schedule, because capacity itself is scoped per pricing item. status is derived at read time from the dates: SCHEDULED before start_at, ACTIVE while the seat is occupied, ENDED after end_at. Ending an assignment is a PATCH that sets end_at, which must be strictly after start_at; clearing end_at re-opens the seat. On its own this changes no billing behaviour: it is the record that makes seat-owned credits and occupied-versus-paid reporting possible. Four permissions govern it, SEAT_ASSIGNMENT.VIEW, SEAT_ASSIGNMENT.CREATE, SEAT_ASSIGNMENT.UPDATE and SEAT_ASSIGNMENT.DELETE, with the viewer role rolled into Read Only. See Seat assignments.
Preview an invoice for a subscription that has only draft schedules A subscription whose schedules are all still drafts could not be previewed: with no active schedule there was nothing to price, so the preview refused rather than showing what the drafts would produce. The preview now includes draft schedules, which is what makes a draft subscription reviewable before anyone activates it.
Draft schedules behave as one unit on a draft subscription While a subscription is itself a draft, every schedule on it is a draft too, so the per-schedule draft chip, the per-schedule activate action and the “Create as draft” toggles added noise around a decision that is not yours to make yet. On a draft subscription these are gone: schedules are created as drafts and all of them are activated together when you activate the subscription, from a single button. On an active subscription new schedules are still created as drafts, and the existing per-schedule controls are unchanged.
Sales representatives can add schedules to a draft quote version
Creating a pricing plan schedule required PRICING_PLAN_SCHEDULE.CREATE, which is the permission that governs changing live subscriptions. A sales representative building a quote therefore needed a permission far broader than the work in front of them. Schedule creation now checks which kind of subscription it targets: a quote subscription requires QUOTE_PRICING_PLAN_SCHEDULE.CREATE and is accepted only while the quote version is DRAFT, and anything else still requires PRICING_PLAN_SCHEDULE.CREATE. Adding a schedule to a quote version that has left draft is rejected with a validation error on quote_version_id, since a change to agreed terms belongs in the upgrade quote flow rather than in an edit.
Custom fields carry over to a new quote version Creating a new version of a quote sends the custom fields of the version it came from. The link a CRM establishes through a custom field, an opportunity id in particular, survived into the subscription when a quote ran straight through, but was lost as soon as the quote was rejected or returned to draft and continued from a new version. The subscription created from that version now carries the link. See the Salesforce quotes integration.
A new invoice PDF renderer, in preview Invoice PDFs can be produced by the same rendering service that already produces quote PDFs, which brings invoices onto one templating and localisation stack: the layout is built from the same component library as the rest of the product, and the invoice template ships translations for the languages the customer portal supports. It is opt-in while it is being rolled out. Contact your account manager to have it enabled for your platform.
An auto rescue stops when the invoice is paid another way
An invoice payment refused for insufficient funds schedules an automatic rescue with the payment provider. If the platform then settled the invoice through POST /v1/invoices/{id}/pay, the rescue still fired later and charged the customer a second time, leaving a refund to be issued. A successful invoice payment now cancels any pending auto rescue for that invoice, and a second auto rescue is not started for an invoice that already has one active. See dunning and payment retries.
Delete a draft workflow
A workflow in DRAFT can be deleted, in line with the other draft resources: subscriptions, customers and pricing plans. A workflow that was created by mistake, or that was superseded before it ever ran, no longer has to be left in place. Deletion is governed by the new WORKFLOW.DELETE permission, and only draft workflows are deletable; an active one still has to be deactivated rather than removed, so no execution history disappears.
Expand the trigger on an action execution
GET /v1/workflow-action-executions/{id} and POST /v1/workflow-action-executions/search accept expand[]=workflow_trigger_id, which inlines the full workflow_trigger that produced the row. Building a list of executions with the resource each one acted on was a second call per row; it is now part of the search response. Successful email actions also record a more useful reason, naming the invoice and the message id the provider accepted, so a delivery can be traced from the execution log into the provider without correlating timestamps.
More template variables on the send-email action
The native send-email action now passes invoice_type, open_amount, customer_name, customer_type, credit_note and original_invoice_number to the template alongside the variables it already sent. Templates written against the legacy Paragon-based Mailgun integration relied on these, and rendered them as empty values after the migration to native workflows. Migrated templates that use them render correctly without being rewritten.
Action execution details in Desk A workflow action execution opens into a details panel showing what the action did, the trigger it came from and the outcome it recorded, rather than only the row in the executions table.
Consistent metric selection on products The billing metric selector on a product item follows the same pattern as the rest of the side panel, and the meter filter, tiering metric and unit names moved into a context menu next to it. Choosing what a usage-based item measures looked different from every other field around it, and each of the related settings used its own control.
The integration reference explained where it is used The reference on an integration is what makes a multi-account setup possible: several integrations of the same type on one platform, told apart by their reference. The dialog now explains what the reference is for and what to put in it, rather than presenting an unexplained field.
📬 This release completes localized emails. use_template_subject sends no subject override, so the provider uses the subject of the same template as the body. Each email also has a threading header. Gmail therefore no longer puts the invoices and reminders of one customer in a single conversation. Wallets get two changes. expand[] gives you a wallet type and its automatic top-up configs in one call. Solvimon also compares a top-up threshold in the unit of the wallet balance. Draft pricing plan schedules, which the API got last release, now have a full editor in Desk. Price indexation has its own page. Two silent errors also stop: Solvimon validates filter values against the meter property type, and Desk reads the invoice payment status from payment_status. Editable meters from ingestion and a pass on the Desk buttons and sidebar complete the release.
Filter values are checked against the meter property type
A usage-based product item can filter on a meter property. Before, Solvimon did not check the filter value against the type of the property. For example, Solvimon accepted EQUALS 1hello1 on a NUMBER property. The filter then matched no events, and the item stayed at zero usage. There was no indication of the cause. Solvimon now validates each value on a NUMBER meter property when you configure the item. An invalid value gives a values.{index} error that names the value and the property. STRING and ENUM properties do not change.
PATCH could add two configs with the same meter property conditions. Solvimon also compared a nested condition group only with its sibling groups, and not with its parent group. A child group could therefore repeat a condition of its parent group. Two configs can no longer claim the same usage. See Filtering on a meter property.Expand the wallet type and the automatic top-up configs on a wallet
GET /v1/wallets and GET /v1/wallets/{id} accept expand[]. There are two expansions. wallet_type_id gives you the full wallet_type. auto_top_up_configs gives you the automatic top-up configs of that wallet. Before, you needed three calls to get a wallet with its denomination and its top-up rules. You now need one call.
The same expansions apply if you get the wallet through the customer balance call. Use the nested key: POST /v1/customers/{id}/wallets/balance?expand[]=wallet_balances.wallet_id&expand[]=wallet_balances.wallet.wallet_type_id.
Draft schedules in Desk You can now build and release draft pricing plan schedules from the subscription screen. The API got them last release. You add a schedule as a draft, and you can edit it while it is a draft. You then activate it from the row actions or the context menu. The schedule list shows which schedules are drafts. You can therefore see a pending renegotiation, and you do not mistake it for the current terms. Activation obeys the permissions of the API. A user who cannot activate a draft sees a disabled action, and does not get an error on save.
Pricing plans on a schedule are collapsible The pricing plan and its connected pricings on a subscription or quote schedule are now a card. You can collapse the card. A subscription with several schedules stays easy to read. You do not scroll past pricing detail that you do not need.
Select or deselect a whole pricing group Multi-select pricing groups on subscription and quote schedules now have a control that selects and deselects all pricings. Before, you enabled each pricing in the group with a separate click. This is the usual case if you sell a plan in full.
Index a subset of revenue items If you apply price indexation to revenue items, a percentage is no longer necessary on each item. If you leave an item empty, Solvimon does not index that item. You can therefore raise one revenue item, and not enter a value for the other items. The API accepted a partial set before this change, but the form did not.
payment_status, and no longer from the deprecated paid flag. If payment_status is not present, Desk uses paid. Desk now shows each status between unpaid and paid, for example PARTIALLY_PAID. Before, Desk showed these statuses as “not paid”.DONE. Before, the label showed “Done”, but the icon continued to spin.Use the subject defined in the email template
Before, a send-email workflow action had an optional subject. If you did not set it, Solvimon used a hard-coded English subject. You could not complete a localized email. The body came from the localized template, but the subject did not. use_template_subject sends no subject override, so the provider uses the subject of the template that it renders. The default is true if the action has no subject. An action that has a subject continues to send it. You cannot use the two fields together. If you set both fields, Solvimon rejects the request with a validation error on use_template_subject. To use the subject of the template, remove the subject. See Subject lines.
Each email starts its own conversation
Each workflow email now has an X-Entity-Ref-ID header. The value is unique to that email, and comes from the action and the trigger. Some mail clients group messages by this header. Gmail put the invoices and reminders of one customer in a single conversation. It then hid the most recent message behind the older messages. Each email now starts its own conversation. See Threading.
PENDING and NOT_EXECUTED statuses. NOT_EXECUTED shows that the conditions of the action did not apply. PENDING shows that the action has not run. See Execution statuses.Edit a meter created during ingestion
Before, you could use a meter from dynamic meter creation, but you could not examine it. It was only a name in a dropdown. The Show meter action on the meter dropdown now opens a side panel. In the panel you can see the meter, and make its values and properties required. You can also add new values and properties, and add more values to an existing ENUM property. You can therefore make a meter from your event stream into a deliberate definition. You do not create the meter again.
Reporting metrics show their aggregation
A reporting metric on a revenue item becomes read-only after you set it. Before, the read-only state showed only the name of the meter. Two revenue items with the same meter and different aggregations looked the same. You could not see a mistake. The state now shows the aggregation with the meter, for example SUM of Amount.
A link that creates a new quote version The create new quote version action is now also available as a link. An external system can send a user directly into a new version of a quote. The Salesforce quotes integration uses this link. The user starts the new version from the opportunity, and does not first find the quote in Desk.
Consistent action buttons Action groups now use one pattern in all screens. One action is a single primary button. Two actions are a primary button and a secondary button. Three or more actions are a primary button and a context menu. The context menu always has the horizontal ellipsis icon. An action no longer moves between a row of buttons and a hidden menu on different screens.
A sidebar section with one page is a link A sidebar parent with only one visible child is now a link, and no longer an expander. The link has the name of that child page. Product catalog is now Products. Payments keeps its own name, and does not show the child name “Overview”. Usage metering also changed: Files is now a tab and not a submenu, and Reprocessing is under Insights.
Clearer labels on the wallet balance box The wallet balance box on a customer now shows correct labels. The first figure is “Available balance”. This is the open balance, which is the balance minus the reserved amount. The second line gives the name of the wallet type, and no longer repeats the word “Balance”. You can also create a credit and use it in one step. “Save and create wallet” on the credit panel saves the credit type. It then opens the wallet panel with that credit type selected.
✍️ We know that a renegotiated contract is rarely one edit, and until now every edit was live the moment you saved it. This release is about getting a change reviewed before it bills: pricing plan schedules gain an explicit draft status with an approval gate, pricing categories can finally be reordered on a plan version, and workflow trigger conditions get a proper editor in Desk with nested AND/OR groups. On the invoicing side, tax summaries are split per rate, wallet grants are reversed when an invoice is voided, and an invoice containing a deduction can reach PAID again. A reactivate action for deprecated meters and clearer custom field ownership round out the release.
Draft status on pricing plan schedules
A pricing plan schedule now carries an explicit status, either DRAFT or ACTIVE, defaulting to ACTIVE so existing integrations are unaffected. A draft schedule can be prepared and reviewed before it takes effect, which is what an approval flow needs; initializing a subscription with status ACTIVE is rejected when its earliest schedule is still a draft, so a subscription cannot go live against a schedule nobody signed off on. The read-only approval_status of the associated approval request is exposed on the schedule alongside it. Draft schedules covers the full flow, including the permissions below.
A read-only is_current was added at the same time, combining the schedule’s date window with its status so you can tell what a customer is on today without evaluating both yourself. Drafts are promoted through POST /v1/pricing-plan-schedules/{id}/activate for one schedule, or POST /v1/pricing-plan-schedules/activate?pricing_plan_subscription_id=... to activate every draft schedule of a subscription in one all-or-nothing batch, so a multi-schedule change goes live together or not at all. Two permissions govern this: PRICING_PLAN_SCHEDULE.STATUS.UPDATE to activate a draft, and PRICING_PLAN_SCHEDULE.WRITE_ACTIVE to create, copy or migrate a schedule that is not a draft. A user who only holds the first can prepare changes but not put them live. Quote schedules keep their own quote permissions and are unaffected.
Reorder pricing categories on a plan version
display_order on a pricing category is now honoured. Previously the order of categories on a pricing plan version always followed the order of the product categories in the catalog, and patching display_order through PATCH /v1/pricing-plan-versions/{id} had no effect, so the only way to change how a plan reads was to reorder the catalog itself. Ordering is validated as a complete permutation: set it on all categories or on none, each value unique, and the values covering 1 through the number of categories without gaps. Desk exposes the reordering on the pricing plan version screen.
Tax summaries are split per rate The tax summary key now combines the tax category with the rate instead of the category alone, so an invoice that applies more than one rate within the same category (a mixed-rate AvaTax result, for example) produces one summary line per rate rather than collapsing them into a single line with a blended base. Invoice groups are grouped the same way as the periods and the invoice itself, so the totals reconcile at every level. The Canadian tax engine keys on the combined rate too; it resolves one rate set per customer, so nothing splits there today, but the behaviour is now consistent across engines. Cost prediction follows the same grouping.
PAID again. The payment status compared the paid amount against the invoice total before deductions, but the deducted part is settled through the deduction and is never invoiced, so no payment could ever cover it and the status stayed PARTIALLY_PAID forever. It now compares against the open amount, which is what “paid” means for such an invoice.Trigger conditions in Desk
The conditions tree on a workflow trigger, added to the API in a previous release, now has an editor in Desk. You build comparisons on the fields the trigger exposes, with the comparators allowed for each field type, and combine them into nested AND/OR groups. The recursive tree editor is shared with the meter condition editor, so workflow conditions are no longer limited to a flat list of ANDs while the API accepted nested groups: a rule such as “only for credit notes above $500, or for any invoice of a customer in this segment” can be expressed in the UI.
INVALID_FIELD error but created the quote and its version anyway, leaving an invalid quote behind.Reactivate a deprecated meter
A meter in DEPRECATED status can be activated again from Desk. The transition was already allowed by the API, but the Activate action was missing from the status menu, so a deprecated meter could only be archived, and archiving is the one step in the resource lifecycle you cannot walk back. Deprecating a meter you still need is a common mistake when tidying up a catalog: the meter keeps matching events but is hidden from new configuration, and the fix is now a single action rather than rebuilding the meter and re-pointing every product item at it.
Request a usage report from the invoice The “Request usage report” action stays available on an invoice that already has a usage report. The button previously disappeared as soon as one report existed, so requesting a fresh one meant going to the Reports tab and pasting the invoice id. That is the wrong way round for the common case: a usage report is most often re-requested precisely because an earlier one is now stale, after usage was reprocessed or a dispute made the numbers worth re-checking. Support agents answering “can you send me the detail behind this line” can now do it from the invoice they are already looking at.
Custom fields state which integration they belong to
A custom field created for a system integration now exposes a read-only integration_type next to its integration_id and integration_reference, and the reference itself became read-only, so the link between a field and the integration that owns it cannot drift. Sandboxes seed the Adyen and email integrations with named custom fields (“Adyen Shopper Reference”, “Adyen Balance Account” and so on) under clearly named integrations, so it is obvious which fields are managed for you and should not be edited by hand.
🛒 This release turns the customer portal from a place to look at invoices into a place to change your plan: customers can create a new pricing plan schedule, upgrade mid-cycle, top up a wallet and manage automatic top-ups without touching your product. Around it, invoices gain two display settings (tax per line item and the original customer’s line), the pay link on an invoice becomes patchable, wallet balance workflows can send emails, API keys can be deactivated from Desk, and the events and customer screens received a round of usability work. Wallet insights and a credit burndown graph in Desk round out the release.
Self-serve plan changes
A customer can now create a new pricing plan schedule on their own subscription from the customer portal, which is what a free-to-premium upgrade needs. POST /v1/portal/pricing-plan-schedules takes the pricing_plan_subscription_id and the enabled_pricings the customer selected; the schedule reuses the subscription’s current pricing plan version, and the previous schedule is closed at the new start. PATCH /v1/portal/pricing-plan-schedules/{id} updates an existing one. Self-serve plan changes walks through both calls end to end.
Two start dates are possible. Left out, start_at puts the change at the start of the next billing period. Passed as now (it is only accepted within five minutes of the current time), the change takes effect immediately and the billing period realigns to it, which requires a subscription with billing time EXACT; on a CALENDAR subscription the request is rejected with a message telling you to omit start_at. The subscription’s next invoice is refreshed afterwards so the change is visible right away.
The upgrade and the payment can also be tied together. Call POST /v1/portal/payments/authorize with context type CREATE_PRICING_PLAN_SCHEDULE and a create_pricing_plan_schedule block naming the pricing_plan_subscription_id, pricing_plan_version_id, pricing_id and optional start_at; the schedule is created once the payment is authorized, so a customer never ends up on a new plan with an unpaid balance or the other way round. The step is idempotent: an existing schedule with the same start date is reused rather than duplicated when a retried payment lands twice.
Portal-driven changes are gated on the customer being able to pay for them. The subscription must be ACTIVE and belong to an ACTIVE customer, and it must carry an ACTIVE payment method of that same customer whose type is one of CARD, DIGITAL_WALLET, DIRECT_DEBIT, ONLINE_BANKING or BUY_NOW_PAY_LATER. Prepaid and unrecognized payment methods are rejected.
Wallet top-ups from the portal
POST /v1/portal/invoices/charge-on-demand-pricing-items now charges the customer instead of only returning a preview. The request carries the pricing_plan_schedule_id, the pricing_items to charge (each with an optional flexible_amount for flexible pricing items), a payment_method_id and finalize_immediately; pass preview: true to get the previous preview-only behaviour. This completes the self-service top-up flow for credit-based pricing: the customer picks a bundle or an amount, pays with a stored payment method, and the wallet grant is booked against the invoice as it is created. See Wallet top-ups.
Automatic top-ups from the portal
Automatic wallet top-ups, introduced through the platform API in a previous release, can now be managed by the customer: /v1/portal/auto-top-up-configs supports creating a config, listing the configs for a wallet_id, fetching one, and the activate and deactivate actions. The config gained a topup_amount field, which is required when the linked on-demand item uses flexible pricing and rejected when it uses a fixed price, so a customer choosing “top up $50 whenever I drop below 100 credits” is expressible without a dedicated fixed-price item. The amount is validated against the item’s flexible pricing band, and the resulting wallet grant is booked synchronously so the new balance is visible the moment the top-up completes.
Available top-ups on the wallet balance
POST /v1/customers/{id}/wallets/balance can now expand charge_on_demand_pricing_items, which lists the on-demand pricing items that can top up each wallet, each with its pricing_item_id, pricing_plan_schedule_id and the expandable pricing_item itself. A portal or in-product balance widget can therefore render the balance and the top-up options the customer is entitled to from a single call, instead of resolving the customer’s schedules separately.
Hide the tax breakdown per line item
A new show_tax_per_line_item setting on the subscription controls whether the VAT breakdown is rendered per invoice line or only as a summary at the total level. It defaults to on, which is the existing behaviour, and the value in effect when the invoice is created is copied onto the invoice (and onto its credit notes), so historical documents keep rendering the way they were issued. Turning it off removes the tax rate column and the per-subtotal “incl. tax” labels from the invoice PDF and the specification page. This is aimed at self-billing setups, where a per-line tax breakdown adds noise rather than information. The toggle is available in Desk under “Edit subscription details”.
Show the original customer’s invoice line
show_original_customer_invoice_line is a new boolean on the platform’s default_pricing_plan_subscription_settings, overridable per subscription, following the same pattern as display_invoice_sub_lines_per_processing_only_customer. The subscription value wins, the platform default applies when the subscription leaves it unset, and the resolved value is stored on the invoice so it survives regeneration and crediting. Desk exposes it in the Edit subscription modal.
Set the pay link on an invoice
The pay_invoice_link on an invoice is now writable through PATCH /v1/invoices/{id}, by passing a portal_url_id. This lets you point a finalized invoice at a specific published portal URL instead of the one Solvimon generates, which matters when you send invoices through your own communication flow. The link must reference a PUBLISHED portal URL that belongs to the invoice being patched, and only a FINAL invoice can be patched. A manually set link takes precedence and is preserved when the invoice is refreshed. See Hosted checkout for how those URLs are created.
credit_details_source in every case (full or partial, standard or one-off), and the toggle now reads as “use the original customer details”, matching what the service does by default.Wallet balance actions and emails The wallet balance trigger now supports actions in general and send-email in particular, so a customer can be emailed when their credits run low rather than only receiving a webhook. Desk supports building these wallet workflows, and the wallet, credit and wallet balance workflow set is seeded in sandboxes so you can try the flow without configuring it from scratch.
Date format selector in Desk
The date_format field on send-email actions, added to the API in a previous release, now has an editor in Desk: you compose the pattern from the supported tokens (yyyy, yy, MMMM, MM, dd and so on) and see a rendered example while typing, so an email that should read 24.08.2026 no longer needs an API call to configure.
Email actions on test platforms
On test platforms, send-email actions now override the to and cc addresses with the platform’s support_email. Testing an invoice email flow against realistic customer data no longer risks delivering it to that customer.
API key status management An API key can now be activated and deactivated from Desk, so rotating a key no longer means creating a replacement and leaving the old one live. The API keys screen gained a Status column and a per-row menu, backed by PATCH /v1/api-keys/{id}.
PATCH /v1/api-keys/{id} no longer returns a 404 for keys that are visible through GET /v1/api-keys. The handler resolved the key against the authenticated user’s entity instead of the platform selected through X-Platform-Id; it now resolves against the request’s platform.Set up your own email provider from Desk Connecting your own Mailgun account to native workflow emails previously required Solvimon to create the system integration for you through the API. Desk now exposes that setup directly, so you can connect and update your mail integration yourself and get the email configuration for a new platform working without a support round trip.
Events table improvements The events table now folds the deleted flag into the processing details column as a red “Deleted” badge (the “Not matched” badge gained an info icon in the same pass), and the reference column is capped at half the container width with truncation on screens below 1200px, so the columns that carry meaning stay readable. In Desk, events can also be ingested for a customer that does not exist yet: the ingest panel can create the customer inline.
Create a customer where you need one The “New invoice” and “Ingest events” panels can now create a customer inline, so a one-off invoice or a first test event for a customer that is not in Solvimon yet no longer means abandoning the form. Creating a customer from the customers screen now navigates straight to the new customer’s detail page.
Wallet insights and credit burndown Insights gained wallet sub-tabs under Usage and Customers, and the customer screen now shows a credit burndown graph under the wallet balance box, so credit consumption over time is visible next to the current balance instead of only in a separate dashboard.
Side column and panel cleanup Content blocks in the side column place the label and the value next to each other in the same size and weight, with the edit control next to the title where the block is editable, which makes the column shorter and easier to scan. Edit and delete were also split into separate actions, so the edit modal no longer doubles as a delete confirmation.
☀️🏖️ Summer is in full swing and we’re not euro-maxxing so this release packs a good bunch of goodies: usage limits with threshold webhooks across the customer hierarchy, a send-webhook workflow action, localized email templates, flexible pricing and tiering conditions in Desk, a guided billing metric setup, and a credit-and-duplicate flow for invoices. Payment error details in Desk and a tidied-up invoice creation flow round out the release.
Usage limits with threshold alerts on the customer hierarchy
You can now store usage limits per customer and get alerted when consumption approaches them, which is the building block for pay-as-you-go platforms that give each end user (modelled as a processing-only child customer) a soft cap. A new UsageLimit resource is managed through POST /v1/usage-limits: it links a customer_id to a meter_value_calculation_id with a limit (a number, amount or credits) and a scope. SELF limits the customer’s own usage; CHILDREN sets a default limit for each child, resolved by walking up the hierarchy to the nearest parent, and a child’s own SELF limit for the same metric overrides its parent’s default.
Alerting is configured through a new USAGE workflow trigger type: the workflow holds the thresholds (percentages of the resolved limit, or absolute values) while the limit itself stays per customer, so one platform-level workflow covers every customer and seat. Each threshold crossing fires the workflow’s actions once per billing period.
Two supporting pieces ship alongside it. GET /v1/usage-limits/status returns the current-period consumption against the resolved limit per customer (with include_children=true to cover a whole hierarchy), giving you the numbers for an in-product usage dashboard. And POST /v1/workflows/init idempotently ensures a workflow and its actions exist by reference, creating them when missing and leaving them untouched otherwise, so provisioning can be scripted safely.
Send a webhook as a workflow action
A new SEND_WEBHOOK action type delivers a workflow’s trigger payload to one of your registered webhooks, referenced by webhook_id in the action’s send_webhook block. Combined with usage-limit workflows this produces usage.threshold_reached notifications carrying the customer, the metric, the threshold that was crossed, the resolved limit and the consumption, so your platform can react to usage events in real time.
Localized email templates
Send-email workflow actions gained a localize_template_names toggle. When enabled, the action appends the end customer’s locale to the template name at send time (for example credit.invoice_en-us) and looks that template up with your email provider, falling back to the base template when no localized variant exists. This matches the behaviour of the legacy Paragon email integration, so platforms sending invoice emails in their customers’ languages can migrate to native workflows without losing localization. Desk exposes the toggle, and the support email field from the previous release, in the send-email action settings.
Flexible pricing in Desk
Flexible pricing, where the customer chooses how much to pay within a band and receives wallet credits in proportion, could previously only be configured through the API. The Desk pricing editor now supports the FLEXIBLE pricing type directly, including the minimum and maximum amounts and the credit conversion, so self-service top-up pricing can be set up without code.
Tiering conditions in Desk
The pricing item config editor now includes an editor for tiering_conditions, the filter that decides which events count toward a config’s tier for product items with a tiering metric. You build the same AND/OR/XOR expression tree used for product item conditions, using the properties of the tiering meter; a config without tiering conditions keeps counting every tiering event. The editor only appears when the product item actually has a tiering meter value calculation, matching the API’s validation.
Clearer tiering tables and custom unit names Tiering tables in Desk now state explicitly which range each tier covers, and custom unit names you define on a product item are now used consistently across the pricing screens instead of a generic “units”. Pricing screens now read the way you’d explain the pricing to a customer, which makes it easier to spot a misconfigured tier before it reaches an invoice.
Guided billing metric setup Picking the billing metric while setting up a revenue item was redesigned into a guided flow, so you can create a new product and its pricing in one go without first learning how meters, meter values and calculation methods fit together. You select the meter, then the meter values and properties attached to it, then the usage metric (calculation method), and a summary text describes what the resulting metric measures. Anything missing can be created inline; choosing “add” opens the meter panel pre-filled for the meter you were configuring, so first-time setups no longer bounce between the products and meters areas. This flow is new and we’re actively shaping it, so if it helps (or gets in your way), tell us: we’d love to hear how it works for your setup.
Edit metric filters on active product items Metric filters on a product item can now be edited while the item is active, instead of requiring a new draft version for a filter change. Small corrections, like excluding a test event type you forgot to filter out, no longer force you through a full version cycle.
Navigation cleanup Features moved out of the product catalog submenu, and the products list now loads 50 items per page so most catalogs fit on a single page.
Credit and duplicate an invoice in Desk The credit flow in Desk can now credit an invoice and create a duplicate in one action, which is the common way to correct a finalized invoice: the credit note cancels the original and the duplicate gives you an editable draft to fix and re-send. Previously this combination was only available through the API.
Pricing plan schedules on the invoice
Invoices now expose a read-only pricing_plan_schedule_ids field listing the pricing plan schedules the invoice bills for, next to the existing pricing_plan_subscription_ids. Because an invoice can span multiple subscriptions and can include usage and pay-in-advance fees from different schedules around a cut-over, this is a list; it lets you trace every line back to the schedule that produced it without expanding each line.
Invoice creation flow cleanup Creating an invoice in Desk was reworded and tidied up, so occasional users, like a support agent issuing a one-off correction, can find the right action without guessing what a button does: the one-off invoice action and button were renamed to say what they do, the report request form was rebuilt, the two “Add” buttons on the invoice were joined into one, the list filters now sit on a single row, and the paid status filter uses a clearer select component.
Payment error details in Desk
When a payment ends in an error, the payment side panel now shows the result details including the external_reason returned by the payment service provider (for example a missing acquirer account for a card type and currency), so you can diagnose a failed payment without pulling the raw API response.
Subscription form and overview cleanup The new-subscription form and the subscription overview page were decluttered: redundant fields and sections were removed and the remaining information was regrouped, making the common path through creating and inspecting a subscription shorter.
This release introduces automatic wallet top-ups, workflow trigger conditions with configurable email variables, rate card discounts below the invoice level, richer usage reports, and Paragon multi-account support, alongside a broad set of Desk improvements across invoices, products, subscriptions and event ingestion.
Automatic wallet top-ups
Wallets can now be topped up automatically when their balance runs low, so a customer on credit-based pricing never stalls because their credits ran out. You create a config through POST /v1/auto-top-up-configs with the wallet_id, a threshold (an amount or a number of credits, matching the wallet’s denomination), the pricing_plan_schedule_id and pricing_item_id of a one-off on-demand item that grants credits to the wallet, and the payment_method_id to charge. Whenever the balance drops below the threshold, the charge is executed through the existing on-demand flow against the stored payment method. Configs can be switched on and off through the activate and deactivate actions, and this also works with flexible pricing items.
Wallet grants are no longer prorated When a subscription change starts mid-period, pricing item configs that carry wallet grants are now charged at the full price and grant the full number of credits, instead of being prorated. This makes mid-period upgrades work as customers expect for credit bundles: someone who runs out of credits halfway through the month and upgrades receives the complete credit allowance of the new tier immediately. Items without wallet grants are still prorated as before.
Discounts on rate cards at every level
Rate cards previously only accepted discounts on the invoice total; a discount on a product, product item or condition was rejected. Discounts within subscription schedules can now target all levels, including a new product_item_meter_property_conditions clause type for discounting a specific meter-property condition of a product item. This removes a common blocker for platforms that offer their merchants item-specific discounts but want the bulk-update convenience of rate cards.
Fixed amounts for tiered pricing on amount-based metrics in Desk When a usage metric is amount-based, Desk previously only offered percentage-based tier prices even though the API already accepted fixed amounts. The pricing editor now lets you choose between a percentage and a fixed amount per tier, so this setup no longer requires the API.
Copy pricing plans with indexing across currencies and billing periods Copying a pricing plan that combines multiple currencies and/or multiple billing periods now carries the pricing indexing configuration over to the copy, instead of dropping it.
Equals comparator is no longer offered for discount conditions, in the API and in Desk. A discount condition compares against a usage total, where an exact-equality match is ambiguous; the remaining comparators (greater/less than) express the intent unambiguously.Guided product setup in Desk The product catalog area of Desk received a set of usability improvements: the new-product modal was streamlined, selecting a revenue type now explains what each type means, the empty state points you to the next step, and naming was aligned across the UI (including renaming the pricing “amount type” to “Tax behavior”, which is what it controls). Activating a product item now shows a confirmation overlay summarizing the effect before you commit.
Ingest page improvements in Desk The manual ingest page (now called “Ingest event”) is easier to work with: the meter and reference fields are searchable selectors, and typing a name that doesn’t exist yet offers to create the meter on the spot, building on dynamic meter creation. Existing meters are summarized in a card instead of raw input fields, the code example was restyled, and the Events menu was reordered to Events, Meters, Files, Reprocessing log.
Trigger conditions
Workflow triggers now support an optional conditions tree that gates whether the workflow’s actions run. A condition node is either a COMPARISON (a single trigger field evaluated against a value) or a GROUP combining nested conditions with an AND/OR operator, so you can express rules such as “only run this action for credit invoices”. Conditions are evaluated when the trigger fires, and each execution records the evaluated tree in conditions_result_tree, so you can see in the execution audit exactly why a workflow did or did not run.
Date format and support email in email actions
Send-email workflow actions gained two configuration fields. date_format controls how date variables such as invoice_date and invoice_due_date are rendered in the email, so dates can match your locale or house style (for example DD.MM.YYYY instead of YYYY-MM-DD). support_email is exposed to email templates as the support_email variable and falls back to the action’s reply-to address when not set.
Fetch a single action execution
A workflow action execution can now be fetched directly through GET /v1/workflow-action-executions/{id}, instead of misusing the search endpoint to look up one record. Desk uses this to show the details of a single execution.
Invoice screen improvements in Desk The invoice detail screen now combines the summary and invoice details into one view, shows a “Credited” label next to the status of an invoice that has been credited, and drops the due date column from invoice tables where it added noise. The context menu actions were reordered by frequency of use, and adding items to a one-off invoice received copy and interaction improvements.
Original or current customer details on one-off invoice credits The choice between keeping the original customer details or using the customer’s current details, introduced for standard credit notes in the previous release, is now also available when crediting a one-off invoice.
Clearer billing timing and currency selection in Desk The subscription form now explains the difference between Exact and Calendar billing when you pick a billing timing, and shows a billing currency selector when the selected plan supports multiple currencies, so multi-currency plans can be subscribed in the right currency without leaving Desk.
Paragon multi-account setup
Platforms that run multiple instances of the same ERP integration (for example one Xero account per billing entity) can now model this through Paragon’s multi-account authorization. A new ERP integration type with the PARAGON_MULTI_ACCOUNT variant represents one Paragon multi-account as a single Solvimon integration, and a paragon_external_ids custom field on the synced resources controls routing: webhook deliveries are fanned out per account, each carrying the X-Paragon-Credential header for the target account, so every object lands in the right ERP instance.
Usage report improvements
The usage report now breaks the currency conversion chain into its two actual steps and shows the tax-inclusive cost. New columns: Cost Amount Quantity Including Tax (the event’s cost in the invoice currency including tax), Billable Metric Quantity and Billable Metric Currency (the metric in its original currency), Pricing Currency, Metric to Pricing Exchange Rate, and Pricing to Invoice Exchange Rate. Previously only a single exchange rate between the metric currency and the invoice currency was reported, which hid the intermediate pricing-currency conversion. The precision of the cost amount quantity movement columns was increased as well.
AI chat on Insights The Insights area now embeds an AI chat assistant, so you can ask questions about the data behind your dashboards in natural language instead of composing filters by hand.
Redesigned side panels and schedule actions Side panels across Desk were restyled with a consistent footer and close button, the subscription and quote view screens use explicit action buttons on schedules, and “Expand all” on pricing plan schedules now renders expanded sections only when they scroll into view, keeping large plans responsive.
X-CLIENT-VERSION header, which could block portal API requests from the browser.This release introduces pricing plan groups, an invoice cadence that is independent of the pricing period, reverse-a-payment support, dynamic variables in quote templates, and a clearer payment status on invoices, alongside subscription, customer and integration improvements.
Pricing plan groups
A new PricingPlanGroup resource lets you group related pricing plans together with the rules for moving between them (upgrade, downgrade and cancellation timing). A pricing plan belongs to at most one group. Create and manage groups through POST /pricing-plan-groups and the accompanying CRUD endpoints; a read-only link field on the pricing plan shows the group it belongs to. This release adds the resource and its management API; executing an upgrade or downgrade on a subscription through a group follows in a later release.
Invoice cadence independent of the pricing period
Pricing item configs now support a billing_period that is separate from the pricing_period, so you can invoice on a different cadence than the one used to price usage (for example price per month, invoice per quarter). In Desk, single-cycle recurring and per-seat product items gain a “Billing period” field to set this cadence without editing the pricing period.
Cancellation reason When cancelling a subscription you can now pass an optional free-text cancellation reason on the POST /v1/pricing-plan-subscriptions/{id}/cancel request. It is persisted on the subscription and is available through both the API and the customer portal, so you can record why a subscription ended.
Keep indexing overrides when copying a schedule Copying a subscription schedule in Desk now carries over its indexing overrides, so a copied schedule keeps the index adjustments you already configured instead of resetting them.
Payment status on invoices
Invoices now expose a payment_status field with the values UNPAID, PARTIALLY_PAID, PAID and OVERPAID, and Desk shows this status on the invoice screen. It gives a more precise view of collection state than the previous paid/unpaid boolean, including partial and over-payments.
Finalize invoices in order An invoice can now only be made final once the previous period’s invoice is already final. This prevents finalizing out of order, where changing an earlier period (for example through included volume) could retroactively affect a later invoice that was already final.
Keep original customer details on a credit note When crediting a standard invoice you can now choose whether to keep the original customer details from the invoice being credited, or use the customer’s current details in the platform. The choice is offered as a radio option in the credit note modal.
Reverse a payment A new reverse action, POST /v1/payments/{id}/reverse, undoes a payment without you having to know its state at the payment service provider. If the payment has not been captured yet it is cancelled; if it has already been captured it is refunded, the same way as a referenced refund. Previously you had to determine capture state yourself and choose between cancel and refund, and a refund on an uncaptured payment would fail.
Dynamic variables in quote templates
Quote templates and drafts now support dynamic variables such as {{quote.customer.name}}, which are hydrated with the quote’s own data when the quote is rendered. This builds on quote templates from the previous release, letting a single template adapt to each customer and quote instead of carrying hard-coded values.
Filter customers by role
The customer list in Desk can now be filtered by role (Self billing, Non processing, Processing only), using the role filter already supported by POST /v1/customers/search. This makes it quicker to narrow a large customer list to the group you care about.
Notification preferences on by default for contacts Contacts now have notification preferences enabled by default, matching the behaviour already in place for customers, so newly added contacts receive the relevant notifications without extra configuration.
Action executions on the workflow detail page A workflow’s detail page in Desk now includes a table of its action executions, so you can see what a workflow has run and monitor its activity from one place.
Type to search meter property enum values Selecting a value from a list-type (enum) meter property now supports typing to filter the options, instead of only scrolling. This is noticeably faster for long lists such as country codes.
The following field is now deprecated. It continues to work for backwards compatibility, but we recommend migrating to the replacement.
paid (Invoice): deprecated in favour of payment_status, which distinguishes UNPAID, PARTIALLY_PAID, PAID and OVERPAID rather than a single boolean.This release brings flexible pricing for self-service wallet top-ups, webhook delivery events with resend, editable payment gateway integrations, Stripe payment-method and 3-D Secure fixes, split-by-meter-property pricing in Desk, and a range of invoicing, quote and meter improvements.
Delete events by reference
Events (meter data) can now be deleted using their reference as a path parameter on the delete endpoint, in addition to the resource id. Previously deleting by reference was only possible via a POST, which made it hard to trace; you can now remove a specific event directly by the reference you sent when ingesting it.
Use non-required meter values and properties in calculations and pricing rules
The required flag on a meter value or property now only governs event validation on ingest; it no longer gates what can be referenced elsewhere. Non-required values and properties can now be used in meter value calculations and in pricing rule conditions, and Desk offers them in the usage-metric and pricing-rule editors. This lets you build calculations and conditional pricing on optional usage data without forcing it onto every event.
Flexible pricing for on-demand top-ups
A new FLEXIBLE pricing type lets a customer choose how much to pay within a range and receive wallet credits in proportion to the amount. You set a minimum and maximum amount and a credit conversion rate on a one-off, on-demand product item; the customer pays anything within the range (for example between $20 and $100) and is granted the matching number of wallet credits. It is charged through the on-demand flow, so it fits self-service wallet top-ups where the customer decides the amount.
Create pricing groups directly on a schedule You can now create pricing groups directly on a pricing plan schedule, without linking them to a pricing plan version, via the pricing group API. This complements pricing defined directly on a schedule, so a schedule’s stand-alone pricing can also include grouped, selectable options rather than only flat pricings.
Split pricing by meter property in Desk Split pricing by meter property is now available in Desk. When a usage-based product item’s meter has meter properties, you can define split pricing on the pricing item config directly in the UI, instead of only through the API. This unblocks setting up contracts that rely on splitting usage across a property (for example per region or per SKU) without hand-crafting the configuration over the API.
Leave the expiry date empty on an upgrade quote
The quote upgrade flow now allows leaving the expiry date empty (expired_at can be null), matching the other quote flows, so an upgrade quote no longer has to carry an expiry date.
Quote flow improvements A set of UX refinements to the quote creation flow in Desk, streamlining the steps and interactions when building a quote.
Clearer “price per X units” on invoices Usage prices expressed per a number of units (for example a price per 1,000 API calls) are now displayed more clearly on invoices, so the unit basis of a charge is easier to read on the document.
Stripe payment method options by currency and amount, and 3-D Secure handling Stripe payment method options are now filtered by the payment’s currency and amount limits, so only methods that actually support that currency and amount are returned; previously a payment in one currency could be offered methods that don’t support it. Alongside this, the Stripe authorisation flow and 3-D Secure handling were fixed so payments complete correctly after 3DS validation, and a Stripe customer is created when needed so the payment method can be stored rather than the payment being taken as a guest.
Webhook delivery events You can now inspect and replay individual webhook deliveries. New read endpoints return the delivery events for a webhook, each including the action that triggered the delivery, the HTTP status code your endpoint returned, the request payload, and any failure details. A resend action lets you re-trigger a delivery after fixing an outage on your side, and Desk adds a matching view in the Developers area to browse a webhook’s delivery events and resend one.
Edit payment gateway integrations
Payment gateway integrations can now be edited after creation. PATCH /integrations/{id} accepts updates to the integration’s name, description and reference, so a typo or a rename no longer requires deleting and recreating the integration. In Desk, Adyen payment gateway integrations now have an Edit option (rotate the API key, update name, description and reference, and configure AFP blocks), and the AFP fields for PLATFORM-type Adyen integrations can now be filled in.
This release brings invoice export to your ERP from a workflow, Stripe in the hosted checkout, price indexing on schedules that carry their own pricing, and a broad set of pricing, quote and subscription improvements in Desk.
Events can be ingested against a specific subscription, by passing a pricing plan subscription id or reference on POST /v1/events/ingest, which is useful when you want usage attributed to one subscription directly. The Event panel now shows that pricing plan subscription, and the subscription id is included in the event metadata, so it’s clear which subscription an event was booked against.
Price indexing when copying a schedule now also works for schedules that define their pricing directly, rather than by referencing a pricing plan version. This closes the gap between two recent additions, pricing defined directly on a schedule and indexing all prices by a percentage when copying, so direct-priced schedules can be indexed the same way as plan-based ones.
Accepting an upgrade quote shows a modal to update the customer’s details, but a sales representative only had view access to customers and was blocked at that step. Sales representatives now have a customer-contributor capability, so they can complete the acceptance flow without being handed broader customer-management rights.
When an approval request for a subscription is cancelled, the subscription is now set back to DRAFT, so it clearly reflects that it still needs to go through approval rather than being left in an in-between state.
When multiple subscriptions are combined onto a single invoice, prices configured including tax and prices configured excluding tax are now handled correctly together on that combined invoice, so the totals are right regardless of how each subscription’s prices were set up.
You can now filter customers by whether they are processing-only, in both the API and Desk, making it easier to find and work with this group of customers.
Stripe payments are now supported in the hosted payment web experience, so customers paying through the hosted checkout can pay via Stripe.
For externally-created payments that Solvimon only receives, rather than initiates, the payment acceptor is no longer required: paymentAcceptorResourceId may be null, since the payment method and acceptor don’t exist in the platform.
A new workflow action lets you export an invoice to your ERP as part of a workflow, so finalised invoices can flow into your accounting system automatically instead of being exported by hand.
The following field is now deprecated. It continues to work for backwards compatibility, but we recommend not relying on it.
total_number_of_pages (paginated list responses): no longer supported; kept only as a legacy page-count value for compatibility.