A returning customer attempts a €120 purchase from an unfamiliar device, and your primary processor asks for authentication. In this hypothetical example, payment fraud orchestration must return to authentication before another authorization attempt. Switching processors alone does not answer that request (Stripe, card decline codes).
For a CTO evaluating a multi-PSP payment stack, the useful question is who owns each decision and what happens when its answer is missing. Start with one transaction, then test the branches where screening, authentication or authorization fails.
Follow the payment fraud orchestration decision gates
Map the same purchase through a proposed flow. Its amount is an illustration, not a fraud threshold. Your risk owner and engineers should agree on the gates before implementing them:
- Establish the order identity, amount, payee and eligible payment credentials. Identify which processors can accept those credentials and which authentication integrations they support.
- Apply your pre-authorization fraud policy. In this example, a rejection stops the attempt, a review decision waits, and acceptance permits the authentication gate. Give errors their own branch.
- Complete any required authentication and inspect its result. Keep the transaction context associated with that result.
- Submit authorization through an eligible processor using your routing policy. Classify the response before deciding whether recovery is allowed.
These are design requirements to evaluate against each integration. They do not establish that an orchestration vendor supplies a fraud engine, a review queue or a particular timeout policy.
Use merchant fraud-prevention techniques to choose controls. This flow determines where they sit and how their outcomes constrain the next payment attempt.
Choose authentication ownership before final routing
Authentication can be separate from authorization. Adyen’s standalone authentication documentation describes obtaining authentication data and subsequently authorizing with Adyen or another PSP. It also specifies integration prerequisites and scheme-dependent expiry.
That supports a possible architecture: screen the transaction, authenticate it, then submit it through a compatible route. A PSP-bound authentication flow may require provider context earlier. Confirm that dependency before drawing a diagram that places all processor selection after authentication.
Ask engineers to record the authentication outcome separately from the authorization outcome. In Adyen’s documented flow, AuthenticationFinished alone is insufficient: the transaction status indicates whether authentication succeeded, failed or requires further action.
For the CTO, the ownership decision is concrete:
- Who implements the 3D Secure flow?
- Who validates the result?
- Who prevents an incompatible route from receiving it?
Resolve those questions before tuning processor-selection rules.
Give each failure its own recovery path
Use these recovery policies as evaluation requirements, then verify the selected providers’ behavior.
Fraud-vendor timeout
Record that screening did not return a usable decision. Your risk owner should choose whether this transaction stops, waits for review or enters a narrowly defined degraded policy. Specify which transactions qualify, who can enable that policy and when it expires.
An API can represent these distinctions explicitly: Gr4vy’s transaction reference separates accepted, rejected, review, pending and error fraud decisions. This example describes Gr4vy’s data model; require separate evidence of any proposed backup fraud screening.
Authentication failure
For this example, stop an attempt whose authentication is denied or rejected. Offer a supported customer recovery path instead of sending it to a different PSP to bypass the result. Treat unavailable or attempted authentication according to the applicable scheme and integration rules, rather than silently mapping either to success.
Demonstrate how each authentication outcome reaches the routing policy, including what the customer sees after an interrupted challenge.
Authentication-required soft decline
Return to authentication. Stripe’s decline-code documentation directs integrations receiving authentication_required to an authentication flow; an off-session payment may require the customer to return. Other decline codes have different next steps.
Preserve the provider’s reason when normalizing responses. A single generic failure label gives the recovery code too little information to choose the appropriate action.
Unknown authorization outcome
Pause alternate-route recovery until the original outcome is resolved. Stripe’s advanced error-handling documentation explains that a network failure can leave a client uncertain whether a request reached the server. Its documented recovery uses the same idempotency key and parameters for that request.
That guarantee belongs to the provider handling the request. As an architecture requirement, maintain order-level attempt tracking across PSPs; a key sent to one provider does not establish deduplication at another. Test status checks and webhook handling before allowing the backup route to create another attempt.
Verify credentials and authentication before fallback
Ask what the stored token represents and where it can be used. EMVCo’s payment-tokenisation explanation describes tokens constrained to a merchant, device or payment scenario. A network token and a vault reference are different inputs to an integration assessment.
For each proposed fallback route, require confirmation of:
- Credential acceptance
- Authentication-data requirements
- Transaction context
Carrying a token successfully does not establish that authentication can travel with it. Primer’s network-tokenization documentation illustrates this dependency through PSP-specific activation requirements for external tokens.
Keep the retry bounded by your approved policy. Confirm that the first attempt has an outcome that permits recovery, the next route accepts the required data and the transaction remains eligible. Record the reason for trying again so the team can distinguish recovery from repeated attempts at a rejected purchase.
Separate Orchestra capabilities from architecture choices
Orchestra’s Library and REST API work together: the Library handles card capture, keeping card details off your servers, and the API handles operations after capture. The customer defines the initial processor and fallback order; Orchestra executes that logic. It does not hold, move, settle, split or disburse funds, and it is not the processor, PSP or acquirer of record.
Evaluate a fraud workflow against that integration model. Require evidence for the particular fraud provider, authentication handoff and error behavior you intend to use. The generic decision chain above is a design to validate, not a list of Orchestra fraud capabilities.
Keep compliance ownership explicit too. PCI SSC FAQ 1588, February 2025 explains script-related SAQ A eligibility for embedded payment forms and directs merchants to their compliance-accepting entity about the appropriate questionnaire. Hosted fields alone do not settle eligibility. Use the compliance outsourcing discussion to separate the provider’s controls from your remaining responsibilities.
The linked technical documentation was checked on September 28, 2026. Except where a publication date is given, these are undated living documents; confirm integration requirements during your implementation review.
Frequently asked questions
What happens if a fraud vendor times out?
The transaction needs an explicit error branch approved by the risk owner. Define whether it stops, waits or proceeds under a constrained policy, then test that behavior. Do not treat the absence of a score as acceptance.
Can authentication be carried to a different PSP?
A supported standalone flow can permit it, as Adyen documents. Verify accepted fields, validity and transaction context for the destination PSP. The existence of one supported flow does not establish universal reuse.
Should every soft decline trigger fallback?
No. An authentication-required decline needs its authentication action, as Stripe documents. Preserve the underlying reason and check the provider’s prescribed recovery before selecting another route.
Does payment orchestration remove PCI obligations?
It does not establish blanket exemption or SAQ eligibility. Review your capture implementation with the entity accepting your compliance validation, following PCI SSC guidance.
Compare the options, then test one transaction
Use the same checklist for direct PSP integrations, an orchestration layer and a dedicated fraud workflow:
- Who owns screening policy, authentication and permission to retry?
- Which exact credential and authentication combinations work on both PSPs?
- What happens on screening timeout, challenge failure and unknown authorization outcome?
- Which records let engineers reconstruct the policy version, decision and provider response?
- What remains your responsibility when the orchestration dependency is unavailable?
- Which costs and latency measurements come from your proposed integration rather than a generic estimate?
Commission one two-PSP spike in the Orchestra sandbox. Ask an engineer to trace the hypothetical purchase through acceptance, authentication-required decline, screening timeout and unknown authorization outcome. Confirm which states the sandbox exposes; use a test harness for unsupported fault simulation. Require a decision trace and an unresolved-capability list before approving production design.
