Map the payment operation before choosing a workflow

Separate the product arrangement, the money-movement instruction and the records you will reconcile.

Start with the arrangement

Modern Treasury’s current Payments overview describes a full-stack payment service provider offering, alongside a route for companies using an existing supported bank sponsor. The PSP description includes payment orchestration, compliance capabilities and account management. Treating the product only as middleware over a company’s own bank accounts misses that distinction. Neither route establishes that a particular business, country, currency or rail is supported for your implementation.

Make a one-page operating map before designing exception handling. Identify the contracting parties, the organization that owns each account relationship, the system that creates payment instructions and the team that handles an unexpected outcome. The map should reflect signed arrangements and verified implementation information, rather than a diagram copied from a marketing page.

Draw records separately from money

A request inside an application, a provider instruction, a bank transaction and an internal accounting entry can describe related activity without being the same object. Give each its own box. Connect boxes only when you know the identifier or evidence that links them. Label an uncertain connection as a question rather than completing the drawing for visual symmetry.

For a fictional supplier-payment workflow, a purchase approval may authorize a future instruction. It does not prove the instruction was created, delivered or settled. A ledger entry can describe the obligation while the payment remains uninitiated. The teaching point is the separation of responsibilities, not a prescribed accounting treatment for supplier liabilities.

Name the people who resolve gaps

For every connecting line, name an owner and a backup role. Product engineering might investigate whether an application sent an instruction. Treasury operations might check the agreed bank channel. Accounting might decide how an unresolved item affects reporting. These are suggested responsibilities to discuss, not claims about Modern Treasury’s support obligations or your employer’s organization.

The bank-integration documentation says bringing an existing bank generally requires coordination and accounts ready for direct transmission. Build readiness questions into the plan: who confirms the connection, how is a test distinguished from production, and what evidence is accepted before opening a new operational route? Avoid assuming an API credential alone means every external dependency is ready.

Define a meaningful completion

Write what success means from each team’s perspective. A technical request can complete while an accounting close still has open work. A customer communication can be sent while the receiving-side outcome remains unknown. A useful map makes those boundaries visible so that a green engineering dashboard does not silently become a promise to a recipient.

Keep a list of unverified assumptions next to the map. Review it whenever a provider arrangement, bank account, product flow or responsibility changes. The objective is a maintainable explanation of the operation. A beautiful but stale diagram is less useful than a plain diagram with current owners and candid unknowns.

A fictional tabletop exercise

Try the map with a fictional new supplier. Begin at the purchase decision and stop at the accounting review. On each connection, write a verb: authorize, create, submit, observe, represent or compare. If two boxes are connected only by the word “process,” ask what actually passes between them. A reference, a status message and money are different things. Then cover the names of the software products. Can someone still explain the operation? If not, the drawing may describe interfaces rather than responsibilities. Restore the product names only after the business relationships are clear. This exercise helps reveal assumptions before anyone configures an integration or tells a colleague that the flow is ready.

Your working questions

1. Which current arrangement applies: the PSP offering, an existing supported-bank relationship, or another verified scope? Record who confirmed this without copying confidential contract terms into a public tool.
2. Which distinct record establishes authorization, initiation, bank observation and accounting treatment? Assign a source system to each answer; avoid calling all four records “the payment.”
3. Who can verify each handoff, and what exact evidence ends the investigation? If no one owns a boundary, treat that ownership gap as part of the work before launch.

Use this as a discussion aid

The workflow in this article is an original educational framework. It is not a product configuration, accounting opinion, contractual promise or instruction to move funds. Keep real records in your organization’s approved systems, with the access and retention rules that apply there. A public documentation review cannot establish your permissions, bank coverage, implementation settings or operating agreements. Ask the authorized owner to verify those details before changing a process.

Source check: October 12, 2026. Product statements are limited to the linked official references below; fictional examples and proposed checklists are editorial teaching material. This independent publication is not Modern Treasury and cannot access an account or investigate a payment.

Continue the investigation

Reconcile three records without flattening their meaning · Choose matching keys that explain why records belong together · A return, a reversal and a correction are not interchangeable