Managing Your Payment, Payout and Identity Providers From One Page

An established money transfer business depends on outside providers at every step: a payment provider to take the money, a payout partner to deliver it, an identity provider to verify the customer, and others for exchange rates, messaging and address lookup. When one of them is half set up or quietly failing, the customer feels it first, as a payment that hangs, a payout that never lands or a verification that never finishes.

The fix is not more vigilance. It is a single place where your team can see every provider, whether it is fully configured, what depends on it and whether it is answering, with the record of every call one step away.

This guide is for operations heads, payments leads and CTOs. It uses RemitSo's 3rd Party Integrations module as the worked example. RemitSo shows the state of each provider, keeps the record of calls and raises alerts in plain language. Your team still owns the provider relationships, the contracts and the decision about what to do when something fails.

Start by listing your providers by job, not by name. In RemitSo the 3rd Party Integrations page groups them into categories:

• Payments: the providers that take customers' money.
• Payouts: the partners that deliver to bank accounts, cash pickup points and mobile wallets.
• Identity checks: ID document, selfie and live face check.
• Exchange rates: the source of base rates, if you use automatic rate feeding, an optional add-on.
• Email and messaging: how customers and staff hear from you.
• Address lookup: the service that helps customers enter an address.

Each category card shows how many of its providers need attention. That gives a morning check that takes seconds: if every card says nothing needs attention, move on; if one does not, open it.

Each provider has its own page. Before anyone changes a credential, switches a route or calls the provider's support team, the page answers three questions.

Is it fully configured?

The page shows whether the provider is fully configured or missing something. A setting left blank after a credential change, or a new provider added but not finished, shows here before it shows in a failed payout.

What uses it?

The page shows what depends on the provider. This is the question people forget to ask before switching something off or rotating a key. If a payout provider carries three corridors, changing it is a three-corridor change.

Is it answering?

The page shows the provider's calls in the last hour. A provider that normally carries steady traffic and shows none at mid-morning is worth a look, even before any alert fires.

Every secret on the page is masked. Operations staff can check a provider's state without seeing live credentials, and a screenshot can go to a partner without leaking access.

A weekly check, written down and owned by one person, catches most provider problems while they are still small. Use the table below as a starting point.

When a payment hangs or an identity check never comes back, the first question is what was sent and what came back. In RemitSo, every call to a payment or identity verification provider is on the record: what was sent, what came back, how long it took and whether it worked. Personal details are hidden and credentials are never stored.

Two logs in System Utilities complete the picture:

• Outbound API logs: every outbound request and response with payloads, headers, status codes and errors, keys masked, filterable to success or failed.
• Webhook logs: every incoming message saved before it is processed, with type, provider, status, attempts, error and time received. The raw message and the reason it failed are one click away, and it can be retried in one click.

The logs show the raw technical error, which is what a provider's support team will search for. The plain-language explanation comes from alerts. For a deeper walk through reading these entries, see reading API and webhook logs without an engineer.

Decide who can read and who can re-apply

Access to these records is set by permission. Reading a provider's message and re-applying it are separate permissions, so a support analyst can read what a partner sent without being able to process it again. Give re-applying to the few people who understand what it does to a transfer. See role-based access control for building roles around this.

Payout partners are set up twice in most operators' heads: once as a technical connection and once as a business relationship. RemitSo keeps both visible. Under Companies, each payout company declares its payout provider and carries its own address, because the regulator asks where money was handed over.

That declaration earns its place in three situations:

• Regulatory reporting: the payout company and its address are on record when a report asks where the money went.
• Partner changes: when a payout company moves to a different connection, the declaration is what to update and check.
• Diagnosis: when payouts fail, the team can see at once which provider page and which log entries to open.

The alert that matters most for this module is "Payout not sent because of a fault on our side". It names whose side the fault was on and whether the partner must be asked before the payout is retried.

Behind it sits a rule that protects customers. RemitSo tells customers a payout failed only when the partner refused it. A fault on the platform's side, or a missing setting, leaves the payout in Error for your team to resend, and the customer is not told it failed. A payout the partner may already hold is never resent without an operator confirming, which is how duplicate payouts are avoided. Payouts are chased on a schedule, and one the partner stops answering about appears on Scout rather than being cancelled.

All of that works only if the alert reaches someone. New alerts reach nobody until someone subscribes, so make sure your payouts owners are on this one. See alert routing for money transfer teams.

The numbers below are illustrative, chosen to show the reasoning rather than to describe any real operator.

An established operator adds a second payout provider for one corridor to spread risk. The payout company is updated to declare the new provider. On Monday morning, 7 payouts on that corridor go to Error, each with "Payout not sent because of a fault on our side". The alert says the fault is on the operator's side and the partner does not need to be asked before retrying.

Step 1: open the integrations page

The payouts category card shows one provider needing attention. The new provider's page says it is not fully configured: one setting was never filled in. Its calls in the last hour: 0. The established provider on the same page shows steady calls.

Step 2: confirm the scope

"What uses it" shows the new provider carries only this corridor. The outbound log, filtered to failed, shows nothing from the new provider, which fits: the payouts never left. No customer has been told anything has failed.

Step 3: fix and resend

The payments lead completes the missing setting. The provider page now shows it fully configured. The team resends the 7 payouts from Error. Within the hour, the provider page shows calls, and the payouts are with the partner.

Step 4: the partner conversation that did not happen

Without the provider page, the team's first move might have been a ticket to the new partner asking why payouts were failing. The partner would have found nothing, because nothing reached it. Instead, the only conversation was internal, and it took minutes.

Established operators add providers for good reasons: a better corridor price, a second route for resilience, a new payout method. RemitSo has 50+ connections to payment, payout, ID check and other partners. Before you sign, ask whether the provider you want is already among them; the answer shapes your timeline.

When it goes live, treat it as the scenario above suggests: confirm the provider page shows it fully configured, check "what uses it", update the payout company's declared provider where relevant, subscribe owners to the payout alerts and watch calls in the last hour on the first day. For choosing partners in the first place, see payout partner APIs.

The 3rd Party Integrations module, with the logs and alerts around it, gives your team one view of every outside provider. See the admin features.

• Providers grouped by category, each card showing how many need attention, so your team runs the morning check in seconds.
• A page per provider showing whether it is fully configured, what uses it and its calls in the last hour, so your team finds a half-finished setup before your customers meet it.
• Secrets masked everywhere, so your team can check and share provider state without exposing credentials.
• Deletion only after typing the code, so your team cannot remove a provider by a misplaced click and your customers are not cut off by one.
• Every payment and identity provider call on the record, with personal details hidden, so your team walks into a partner conversation with exactly what was sent and what came back.
• Outbound API and webhook logs, with separate read and re-apply permissions, so your team diagnoses without an engineer and only trusted staff re-apply a provider's message.
• Payout provider declared per payout company, with its address, so your team knows which connection to check and can answer where money was handed over.
• Faults on your side stay with your team: the payout waits in Error and your customers are not told it failed, while your team gets a plain-language alert to resend.

What your team still does: choose and contract providers, complete their settings, run the weekly check, talk to partners and decide when to resend.

To see the module with your own providers, book a demo.