Frameworks

Ultraner in what you already build with

Taking a mobile-money payment is the same API everywhere. What differs by framework is where your key is allowed to live, and how the framework mangles a request body before your webhook handler sees it. That second one is why signatures fail, and it has a different answer in every one of these.

Live in 14 markets: Benin, Cameroon, DR Congo, Gabon, Ivory Coast, Kenya, Mozambique, Republic of Congo, Rwanda, Senegal, Sierra Leone, Tanzania, Uganda and Zambia.

TypeScript

Next.js

The App Router splits server and client in a way that decides where your API key may live, and route handlers parse bodies differently from Express.

@ultraner/sdk tested against the sandbox

JavaScript

Express

The default JSON body parser is the single most common cause of webhook signatures that never validate.

@ultraner/sdk tested against the sandbox

Python

Django

Django parses and CSRF-protects POST bodies by default, both of which break a webhook endpoint before your view runs.

ultraner

FastAPI

Declaring a Pydantic model on the webhook route is the natural thing to do and it destroys the bytes you need to verify.

ultraner

PHP

Laravel

Laravel applies CSRF middleware to every POST route, so a webhook is rejected before it reaches your controller.

ultraner/sdk

WooCommerce

This is the one entry here that is a real integration rather than a client library: a gateway plugin that appears at checkout without you writing code.

plugin

Dart

Flutter

A mobile app is the one place where the temptation to ship a secret key is strongest, and the payment is asynchronous, so the UI has to wait for something it cannot see.

ultraner

Go

Go

net/http gives you the raw body by default, which makes verification simpler here than almost anywhere else, as long as you read it before decoding.

github.com/ultraner/ultraner-go

Why your framework might not be here

These are the frameworks we have a client and a checked example for. Rails, Spring, .NET and the rest can all call the API perfectly well, and a page saying so would be padding: it would repeat the REST reference with a logo on top and imply an integration that does not exist. The API is plain HTTP and JSON, so the reference and the OpenAPI spec are the honest answer until there is a client worth naming.

API reference Building with an AI agent