Try it right away
A public test instance of the proxy runs at mpp.digital-platform.io. Both sides work against the same instance. The commands are for the shell on macOS and Linux. Anyone can ask how the instance is doing:
curl -fsS https://mpp.digital-platform.io/mpp/v1/health
curl -fsS https://mpp.digital-platform.io/macp/v1
curl -fsS https://mpp.digital-platform.io/macp/v1/capabilitiesThis is how you watch the instance work, whether you mean to offer or to call. A free function can be discovered and called with no SDK, no payment, no credit and no wallet on your machine.
1. Set the address and the function. The following steps use both.
MACP=https://mpp.digital-platform.io/macp/v1
FN=bob.generative-models.list.v12. Find functions. The instance lists everything on offer there, free and paid alike.
curl -fsS $MACP/functions3. Look at the price. For this function it says "mode": "free".
curl -fsS $MACP/functions/$FN/pricing4. Call it. The response carries "status": "succeeded" and contains the list of models.
curl -fsS -X POST $MACP/execute \
-H 'Content-Type: application/json' \
-d "{\"functionId\":\"$FN\",\"input\":{}}"The same flow in more detail, with the function selected via jq and a request ID of your own, is in the developer guide on Codeberg, section Calling a free function.
Last updated: 22 September 2026
If you offer something
The M-Pay Proxy knows your functions and their prices, quotes the price to the caller, takes the payment and then calls your function. You change nothing in your own application; it need know nothing about payment. As long as you only register your own functions, the proxy is nothing you need to attend to. It becomes your own concern once you open your marketplace to further providers: then you enrol them, and the catalogue is kept separately per provider.
How a paid call runs
This is how a paid call reaches you. The proxy quotes the price, takes the payment and only then calls your function. The caller is an agent or an application that buys for its own purposes or on behalf of a customer.
Where the purchase is triggered is up to you. A link or a QR code fits on a page, in an app, in a newsletter or in an assistant. Machines call directly instead.
Setting this up takes three calls.
POST /mpp/v1/admin/merchant-auth # credentials
POST /mpp/v1/admin/execution-backends # backend
POST /mpp/v1/admin/functions # priceWe set up the first registration for you. With the second you store the credentials the proxy uses to call your backend; with the third you register the function, its target URL, its schema and its price.
Registering a function also carries the input and output schema, a timeout, how long the grant is valid and whether it is good once or repeatedly.
What you need beforehand.
- A merchant identifier and a merchant account in the payment backend. Both come out of onboarding.
- An admin token scoped to your identifier alone. We issue that.
- A backend reachable publicly over HTTPS, together with the credentials the proxy uses to call it.
If you are the caller
On the other side sits the Go SDK. Ask the price, get a quote, pay, execute.
c, err := mppsdk.New(cfg)
price, err := c.GetPricing(ctx, "weather-forecast")
limit := price.Pricing.AmountCents
quote, err := c.GetQuote(ctx, mppsdk.GetQuoteRequest{
FunctionID: "weather-forecast",
ExecutionCount: 1,
MaxPriceCents: &limit,
})
res, err := c.PayInvoice(ctx, quote)
out, err := c.Execute(ctx, mppsdk.ExecuteRequest{
FunctionID: "weather-forecast",
GrantID: res.GrantID,
Input: map[string]any{"city": "München"},
})Error handling is omitted for clarity. Paying and executing stay two calls: PayInvoice returns the grant in res.GrantID, and Execute passes it on when executing (POST /macp/v1/execute). The two are deliberately not merged, which is why the proxy reports payAndExecute as false. The result is then in out.Output. Once the grant has expired or been used up, the proxy refuses to execute. Then the same route applies again: ask the price, pay, execute.
This is how you get the SDK:
git clone https://codeberg.org/stulle-ai/m-pay.git
cd m-pay/mpp/sdk/go
go test ./...
go build ./cmd/mpp-sdk-demoYou pull the SDK into your own programs with go get codeberg.org/stulle-ai/m-pay/mpp/sdk/go/mppsdk@v0.3.1. Go 1.25.5 or newer is required. For paid calls the SDK needs the wallet. It runs as a service of its own next to your application, on Linux for now, and is topped up beforehand.
Connecting providers yourself. If your agents buy from a provider that is not connected yet, you register its interface at your own proxy, with the same three calls as above under If you offer something. The provider only makes its interface available.
The components
| NAME | WHAT IT IS | WHERE IT RUNS | WHAT YOU HAVE TO DO WITH IT |
|---|---|---|---|
| NameM-Pay Proxy | What it isSits in front of the provider’s function: quotes the price, takes the payment and then calls it | Where it runsIn your installation, operated by you or by us. To try it out: mpp.digital-platform.io | What you have to do with itIf you offer something: register the function, its target and its price, and further providers once you open your marketplace. If you are the caller: nothing, unless you connect providers yourself |
| NameMACP | What it isThe protocol in between. A purchase takes three calls: /quotes, /pay, /execute | Where it runsBetween caller and proxy. It describes itself at /macp/v1 | What you have to do with itIf you are the caller: no need to call it yourself, the SDK makes the three calls, one after the other |
| NameThe Go SDK | What it isHandles price, quote, payment and execution, and talks to the wallet for it | Where it runsInside your own program, under the MIT licence | What you have to do with itIf you are the caller: pull it in |
| NameThe app | What it isThe buyer’s interface: purchases, deliveries, receipts and cancellation | Where it runsOn the buyer’s phone | What you have to do with itIf you offer something: nothing, we deliver it under your brand |
| NameThe wallet | What it isHolds the credit and produces the payment data | Where it runsFor a person inside the app; for a machine as a service of its own next to your application, on Linux for now | What you have to do with itIf you are the caller: install it and top it up. Credit and keys stay with you |
A complete example
The developer kit holds three runnable programs that together stand in for a publishing house: a server for the issues, an application the publisher uses to upload and set the price, and a kiosk where the reader buys. The recording “Media publishing, start to finish” shows the same flow: a publisher uploads an issue, a reader buys a single article from it for 25 cents.
Version and licence
- On Codeberg. Go SDK, protocol definitions, example programs and the developer guide as source code under the MIT licence. The wallet is available there as a ready-built program for Linux.
- Developer kit 0.3.1, protocol v1 as a draft. The kit carries version number 0.3.1; the protocol exists as a version 1 draft and is not fixed yet. Pin a version of the kit rather than following the moving branch.
- Not included. The proxy and the payment backend. We set them up and, if you wish, run them for you.
- Overview on Codeberg. The admin calls are listed with their purpose and order in the README on Codeberg, section SA-x: administration interface. Requests and responses are not described in detail there yet, so we set up the first registration together with you.
View the repository on Codeberg
What it is built on
NemosGo is the product. Underneath sits M-Pay, the payment and transaction technology. Factory 42 helps us develop and run parts of NemosGo, and powers the AI offerings for customers. You don’t need to know either to integrate. What the two can do is set out under the technology behind it.
Let’s talk
Questions about the integration or the technology? Write to us.