Yes to both, and the reason matters more than the feature itself.
The execution layer of business is shifting to agents. Around 80% of what we run is already executed through agentic solutions rather than a person clicking through an interface, and we don’t think we’ll be unusual in that for long — it’s where most businesses are heading. An agent doesn’t open your dashboard. It calls an API. So anything that exists only in the GUI is, from an agent’s point of view, simply missing.
Here’s the concrete comparison. With Stripe, I can point our AI infrastructure at it and have every product we want created and priced without me touching anything. With PayKickstart, the same work has to be done by hand, one product at a time. Same business, same agents, and PayKickstart is the one platform where automation stops and a human takes over.
I’ll be straight about the consequence: unless this lands, and reasonably quickly, we won’t be building new work on PayKickstart. Not out of dissatisfaction with the platform — the parts of the API that exist work well for us — but because we can’t justify a manual step in the middle of an otherwise automated stack when an alternative doesn’t have one. I don’t think we’ll be alone in that over the next year or two.
The principle worth adopting: everything the GUI can do should be achievable through the API. Not a subset, not just the customer-facing operations — everything. The dashboard should be one client of the API, not the only route to half the functionality. Any capability that is GUI-only is invisible to the agentic layer, and that’s increasingly the layer doing the work.
To be fair, your API is already strong for post-sale customer management — subscriptions, licensing, coupons, add-on credits, affiliates, IPNs all work well for us. The gap is catalogue and configuration, and it’s a hard blocker rather than an annoyance, because there’s no workaround an agent can use.
In priority order for us:
Products and plans — create, update, archive.
Pricing — set and update a plan’s price, including multi-currency. Prices change for reasons outside our control (awarding bodies revising exam fees, for instance), and each change is currently manual, per product, with no test, no review step and no audit trail — while everything else in our stack has all three.
List and GET products and campaigns. There’s currently no way to enumerate the catalogue at all (GET /api/products and /api/campaigns return “route could not be found”), so an agent can’t discover what we sell or verify a price is what we think it is. Read-only alone would be a big step.
Campaign create and update.
Checkout/funnel configuration and IPN URLs per campaign.
There’s a related request on this board for an MCP server for the PayKickstart API — the same trend from another angle. Worth noting the dependency: an MCP server is only as useful as the API beneath it. Without configuration endpoints, it can report on the business but it can’t run it.
Happy to be a test vendor for this if that’s useful.
Log in to comment and vote
Comments1
Station X
Aug 7
Yes to both, and the reason matters more than the feature itself.
The execution layer of business is shifting to agents. Around 80% of what we run is already executed through agentic solutions rather than a person clicking through an interface, and we don’t think we’ll be unusual in that for long — it’s where most businesses are heading. An agent doesn’t open your dashboard. It calls an API. So anything that exists only in the GUI is, from an agent’s point of view, simply missing.
Here’s the concrete comparison. With Stripe, I can point our AI infrastructure at it and have every product we want created and priced without me touching anything. With PayKickstart, the same work has to be done by hand, one product at a time. Same business, same agents, and PayKickstart is the one platform where automation stops and a human takes over.
I’ll be straight about the consequence: unless this lands, and reasonably quickly, we won’t be building new work on PayKickstart. Not out of dissatisfaction with the platform — the parts of the API that exist work well for us — but because we can’t justify a manual step in the middle of an otherwise automated stack when an alternative doesn’t have one. I don’t think we’ll be alone in that over the next year or two.
The principle worth adopting: everything the GUI can do should be achievable through the API. Not a subset, not just the customer-facing operations — everything. The dashboard should be one client of the API, not the only route to half the functionality. Any capability that is GUI-only is invisible to the agentic layer, and that’s increasingly the layer doing the work.
To be fair, your API is already strong for post-sale customer management — subscriptions, licensing, coupons, add-on credits, affiliates, IPNs all work well for us. The gap is catalogue and configuration, and it’s a hard blocker rather than an annoyance, because there’s no workaround an agent can use.
In priority order for us:
Products and plans — create, update, archive.
Pricing — set and update a plan’s price, including multi-currency. Prices change for reasons outside our control (awarding bodies revising exam fees, for instance), and each change is currently manual, per product, with no test, no review step and no audit trail — while everything else in our stack has all three.
List and GET products and campaigns. There’s currently no way to enumerate the catalogue at all (GET /api/products and /api/campaigns return “route could not be found”), so an agent can’t discover what we sell or verify a price is what we think it is. Read-only alone would be a big step.
Campaign create and update.
Checkout/funnel configuration and IPN URLs per campaign.
There’s a related request on this board for an MCP server for the PayKickstart API — the same trend from another angle. Worth noting the dependency: an MCP server is only as useful as the API beneath it. Without configuration endpoints, it can report on the business but it can’t run it.
Happy to be a test vendor for this if that’s useful.