Inbound payment-processor callback (processors only, never called by an integrator)

Inbound. This is where the payment processor tells WalletD that a top-up succeeded or failed; an integrator never calls it. It is documented because it is the path by which a top-up's money actually lands, and because a partner operating its own gateway account has to point the processor at it. There is no bearer token: the processor's own signature over the raw body is the authentication, which is why the body must reach walletd unmodified. A verified terminal outcome is applied through the same confirmation path a manual refresh uses, and an intent already in a terminal state is left untouched, so a replayed callback cannot credit twice. A succeeded outcome whose reported amount or currency disagrees with the intent is parked as amount_mismatch and never credited; resolving that is an operator decision. Failures answer in problem+json like every other operation: 404 gateway_not_found for a gateway this deployment has not configured or that has no webhook, 400 invalid_request for a body that cannot be read, 401 webhook_verification_failed for a signature that does not verify, and 500 internal_error when the confirmation itself fails — which the processor should retry.

Path Parameters

The processor's own event payload, verbatim. The raw bytes are what the signature covers.

Response Body