Wise API Integration Gateway

Built an internal payment gateway using an Azure Function that calls the Wise sandbox API on behalf of authorized callers. The Wise API token lives in Azure Key Vault, never in code, and a system-assigned Managed Identity on the Function retrieves it at runtime through Azure RBAC, with zero credentials stored anywhere in the codebase. A Microsoft Entra ID App Registration gives the service its own governable identity in the tenant, and Elastic Cloud with Kibana provides log-based visibility into the Key Vault access layer.

Once the system was working end to end, I deliberately broke it four different ways (a missing IAM role, a stale credential, a valid but under-permissioned credential, and a bad function key) and diagnosed each failure the way a support engineer actually would: using only the HTTP response and the platform logs available at each layer.

Companies don't send money by manually logging into a payment provider's website. They build internal software that calls the provider's API on their behalf, and that software needs its own identity, its own access controls, and its own credential handling, the same as any other piece of enterprise infrastructure. A script with an API token pasted directly into it is not a real integration, it's a liability waiting to be found.

This project exists to prove a specific, narrow skill: given nothing but an HTTP status code and a response body, correctly identify which layer of a system failed. Two of the four scenarios return the exact same 401 status and would look identical to a customer describing "my token doesn't work," but they point to two completely different fixes. Telling them apart from the response alone, rather than guessing, is the actual job.

With the system working, I deliberately broke it four different ways. First, removed the Key Vault Secrets User role from the Managed Identity. The result was HTTP/1.1 500 Internal Server Error with an empty body, an unhandled exception with no graceful message, and Kibana showed azure.platformlogs.result_signature: "Forbidden" on the matching SecretGet entry, confirming an authorization denial at the Key Vault layer rather than a bug in my code. This one is actually an Azure and IAM-layer issue, something a Wise support engineer would never have visibility into on a real customer's own infrastructure.

The next two scenarios are the real showcase, since both return a 401 from Wise and would look identical to a customer describing "my token doesn't work," but point to two completely different fixes. Second, I created a new Key Vault secret version with a garbage value, simulating a rotated credential that was never updated downstream. Wise returned {"error":"invalid_token"}, while Kibana showed the Key Vault call itself succeeded (isRbacAuthorized: true, result_signature: OK), proving the failure was entirely downstream at Wise and invisible to Azure's own logs. Third, I swapped in a genuinely valid Read-only token and called the write-action endpoint. Wise returned {"code":"error.quote.mustBeAuthenticated"}, a meaningfully different error: the token is recognized as legitimate, it simply doesn't carry enough authentication strength for that specific action. invalid_token needs a corrected token value. mustBeAuthenticated needs the customer to reissue a token with broader access, since their existing one already works correctly.

Restoring between scenarios surfaced a real Key Vault behavior worth knowing. I tried disabling the garbage secret version, assuming Key Vault would fall back to the previous version automatically. Instead it left the secret with no enabled version at all, producing a hard connection failure with zero bytes received, a different failure signature than either the working state or the broken state. Disabling a version does not promote an older version to current. The fix was creating a genuinely new version with the real token, not re-enabling the old one.

Fourth, I called the endpoint with an intentionally wrong function key. The result was HTTP/1.1 401 Unauthorized with zero body content, and no new SecretGet entry appeared in Kibana at all. Unlike the two Wise-side failures, this request never reached the Python code, never touched Key Vault, and never called Wise. The absence of a log entry was itself the diagnostic signal.

The most useful lesson came from comparing the two Wise-side failures side by side. A malformed or incomplete token and a token that is valid but under-permissioned both return a 401, and the response body is the only thing that tells them apart. That distinction changes what I'd ask a customer to do next, and it's the actual diagnostic skill a support ticket is testing, not just recognizing that something failed.

Kibana visibility in this build covers Azure platform logs only, specifically the Key Vault SecretGet events the Managed Identity generates. It has no visibility into what Wise itself returned, so a customer reporting either 401 above would show up in Kibana as a completely successful SecretGet event. Closing that gap means having the Function forward Wise's own status code and response body into a separate log index, giving a support engineer one searchable place to see both what Azure did and what the third-party API actually said. I'm documenting that as the next step rather than treating this build as finished, since the diagnostic evidence I already captured was complete and accurate without it.