Blog
A miniature shop and bank connected by a mechanical relay carrying a blue card and coin.

August 3, 20265 min readАдминистратор

Who owns each payment decision: a responsibility map

Why payments get stuck between support, engineering and finance. Build a decision map, a useful handover and a shift-change test.

“Everything succeeded on our side” is little help when the warehouse cannot ship and the customer has paid. The provider sees a transaction, finance wants a payout, and engineering checks an event. The problem sits between those records. A useful responsibility map identifies who can establish the fact, who may act on it, and who stays with the customer until resolution.

A hypothetical €120 investigation

Consider a shop with a €120 order. The provider records a successful payment, but finance cannot find €120 in the bank account. Someone labels the ticket “missing payment” and sends it to engineering. That assignment is premature: the unanswered question concerns the relationship between a payment and a later payout.

Customer support first connects the order ID to the provider's transaction ID. Payment operations checks the provider record and the expected reporting entry. Finance identifies the payout containing the transaction, then checks its bank reference. Engineering becomes the owner if the provider has a record that the internal system failed to process.

Suppose this invented example has a €3 processing fee and no other movements. The amount after that fee is €117. It would be wrong to tell the customer that they underpaid by €3. It would also be wrong to assume a €117 bank deposit must exist as a separate line: the transaction might be included in a larger payout. The numbers illustrate reconciliation, not any provider's pricing.

Which role does each company actually perform?

The merchant sells the product or service and maintains the commercial relationship with the customer. Its order system should explain what was purchased, what was promised and what has been delivered. A payment record cannot answer all three questions. Nor can a support agent reconstruct them reliably from a bank statement.

A payment service provider, or PSP, supplies payment capabilities to a business. Depending on the arrangement, these can include checkout, connections to payment methods, processing and reporting. A processor handles the technical exchange of payment messages. A single company can perform several functions, as Adyen explains in its PSP overview. The abbreviation on a sales presentation therefore tells you less than the actual service agreement.

In a card payment, the acquirer serves the acceptance side and participates in processing and settlement for the merchant. The issuer supplies the customer's card, with the card network connecting the relevant participants. Adyen's industry glossary defines these roles. A direct bank transfer has a different structure, so a card-chain diagram should not be treated as a universal map of every P2P or account-to-account payment.

Build a responsibility sheet people can actually use

Keep one row per decision rather than one row per company. Record the owner, backup owner, authoritative record and escalation contact. Five decisions deserve particular attention:

  • Who can release an order for fulfilment, and what evidence must exist first?
  • Who confirms the payment amount, currency and current provider status?
  • Who approves a refund commercially, and who verifies its payment outcome?
  • Who explains the difference between transaction totals and the bank deposit?
  • Who updates the customer while another team investigates?

Assigning one customer-facing owner prevents contradictory messages. It does not mean that person needs unrestricted access. Read-only transaction visibility may be enough for support, while changing payout destinations requires a separate, tightly controlled responsibility.

Hand over a question, not an unexplained ticket

“Missing payment” has no testable boundary. Try this instead: “Order O-120 is linked to payment P-817. The provider confirms capture, but the order still awaits payment. Establish whether the event arrived and why the order did not change.” These invented references make the object, last verified state and missing fact explicit.

A useful handover contains the order reference, a link to the authorised provider record, amount, currency, timestamp with timezone, expected versus observed behaviour, and actions already taken. State what is blocked: shipping, a refund or locating a payout. Avoid attaching the entire customer profile when two references are enough.

Require the receiving team to acknowledge the next action. Until it does, the previous owner keeps the case. This is a suggested operating rule, not a payment-network requirement. It closes the gap in which the sender thinks the ticket belongs elsewhere while the recipient has not accepted it.

Ownership does not require every permission

Separate diagnosis, authority to move money and customer communication. An engineer may prove that an event was missed; an authorised operator still decides whether a refund is appropriate. Support can own the conversation without being able to change payout destinations. The arrangement preserves momentum without turning each incident into a reason to broaden access.

Test the map at a shift change. At 6 p.m. the primary specialist leaves. Their replacement should be able to find the evidence, understand the risk of a repeated action and identify the next update time. If the answer lives in the departing colleague’s private chat, the operation is more person-dependent than the diagram suggests.

In weekly reviews, count handovers and time spent without an assigned next action. These measures expose organisational delay separately from waiting for a bank. Close the investigation when the records are linked and the intended action is confirmed, rather than when someone sends one more request to “check your side”. Keep that resolution evidence with the original case.

Two arrangements worth checking explicitly

First, identify any platform or payment facilitator between you and the acquirer. A facilitator can onboard sub-merchants and receive settlement funds for onward payment, according to Adyen's definition. Ask who contracts with your business, who owes each operational response and which entity actually sends payouts. Get an answer for your geography and setup.

Second, document data-security responsibilities. PCI SSC explains that outsourcing payment processing does not eliminate every merchant responsibility. Confirm the applicable validation requirements with the organisation that manages your compliance programme, rather than assuming a hosted checkout settles the question.

Before launch, give the next shift one open case without a verbal briefing. Ask them to identify the missing fact, where to check it and who owns the next action. If the case record cannot answer those three questions, improve the handover itself.

Sources

  1. 1.adyen.com/knowledge-hub/payment-service-provider
  2. 2.help.adyen.com/en_US/guides/franchisees-basics-guide/industry-terms-to-know
  3. 3.help.adyen.com/en_US/knowledge/compliance/compliance-with-card-scheme-rules/what-is-a-payment-facilitator
  4. 4.pcisecuritystandards.org/faqs/does-pci-dss-apply-to-merchants-who-outsource-all-payment-processing-operations-and-never-store-process-or-transmit-cardholder-data

Comments · 0

No comments yet — be the first.

Log in · log in to leave a comment.