WunderCorp MPP and conventional API billing assign responsibility differently

Most commercial APIs assume that a person or company creates an account before software makes the first request. The account holds payment details, usage records, and a contract that persists beyond one task.

Stripe’s 2025 annual update reported that its programmable financial services support more than five million businesses. Account based billing remains effective because it combines identity, payment, tax, and support in a durable relationship. We regard the figure as a starting point for measurement rather than proof of a finished business case.

Machine payment protocols address a different case. A software process may discover a capability during a task and need one bounded result without creating a long lived account or exposing reusable payment credentials. Our interpretation remains conditional: the same technology can create value or move work into a less visible queue.

Account billing carries services that a single payment request does not. It can support negotiated terms, tax records, credit limits, and customer service. Those functions matter when the relationship is ongoing or the buyer expects recourse beyond one result.

We hold that machine commerce requires explicit prices, permissions and settlement records. Autonomous purchasing without those records creates accounting and security debt.

Our position informed the design of WunderCorp MPP. WunderCorp MPP publishes priced API outcomes that can be discovered and purchased programmatically. The transaction can be associated with the specific request rather than a monthly plan.

We regard measurement as part of the product decision. Conventional billing is stronger when usage is frequent, support is important, or contractual terms need negotiation. Machine payment is attractive when the purchase is small, standardized, and easy to verify.

Responsibility also moves. Account billing places more policy with the seller and the account administrator. Per request payment places more policy with the calling agent and its budget controls.

Per request payment reduces the commitment required for a small standardized purchase. It can also move more risk into the protocol because identity, authorization, and delivery must be resolved during the transaction. The appropriate model follows the commercial relationship: recurring service favors an account, while a bounded result may justify a bounded payment.

Tax, refunds, and customer support can favor an account relationship even when each call has a clear price. A persistent customer record gives the seller a place to issue credits and communicate changes. A per request system can provide those functions, but each addition makes the transaction resemble a lightweight account. The boundary will differ by product and jurisdiction.

Credit risk differs between the models. Account billing can allow usage before settlement and collect payment later. Per request payment can require authorization before delivery, reducing unpaid balances while adding transaction overhead to each purchase. Sellers with high volume and trusted customers may accept the former. Sellers of occasional automated outcomes may prefer the latter.

We would change our position if the operating results failed to improve. The two models are likely to coexist. The decision depends on whether the commercial relationship is the product or whether the client mainly needs one defined outcome.