Hyperswitch fraud integration with Signifyd and Riskified

The first decision is whether the fraud check runs before the processor authorizes the payment or after it. Hyperswitch documents two FRM flows for this choice. The pre-authorization flow applies to any payment method, and its documented action is to continue when the provider accepts the order. The post-authorization flow applies to cards only and offers three outcomes: continue to accept, halt on decline, or approve or decline on review. Your payment mix therefore sets the options before any other trade-off applies. If wallets or other non-card methods carry meaningful volume, pre-authorization is the only documented flow that covers them.

The main trade-off is the cost of a declined or held order. Pre-authorization screens the order before authorization, so a decline ends the order before the processor is asked to authorize it. Post-authorization lets the processor authorize first, which means a decline or a review hold can leave an authorized amount that you must void or release, and a held order can tie up inventory while a reviewer decides. Ask Signifyd or Riskified how they bill per decision and whether review outcomes carry extra fees. Confirm with your processor how voids and captures behave for authorizations that sit in a hold.

Both flows add provider response time to checkout. The difference is where that time falls in the payment sequence. Pre-authorization places the fraud decision before the authorization request, so the shopper waits for the screen before learning the payment result. Post-authorization waits for the authorization first and then waits for the fraud decision, so the shopper may see an approval that is later declined or held. No latency figure for either provider is supplied here. Measure both flows in a sandbox at your expected peak order volume, and define what the checkout does if the provider times out.

The flow choice also decides which provider flows run. Checkout and Transaction run under both Hyperswitch flows for Signifyd and Riskified. Sale runs for Signifyd only, so a Riskified integration has no Sale step to build. Fulfillment and RecordReturn run after the order ships or is returned, and the Hyperswitch docs for both providers state that chargeback liability shift requires the Fulfillment call after shipment. Before build, produce a table that lists each provider, each flow and the system event that triggers it, including the shipment and return events your order management system must emit.

The fulfillment call is the step that moves chargeback liability, so its timing and content matter more than most teams expect. The Hyperswitch docs for both Signifyd and Riskified state that liability shift requires the Fulfillment flow to be called after shipment. The earlier checks in the Hyperswitch FRM workflow, pre-authorization for any payment method and post-authorization for cards, decide whether an order is accepted, halted or sent to review. Fulfillment is a separate signal that tells the provider goods have left your control. If the call is wired to order creation, you may receive a decision on the order but lack the shipment evidence the provider needs to take on the risk.

Design the trigger in your order management system, not in the payment path. Fire it from the shipment confirmation event that your warehouse or fulfillment service emits once the carrier accepts the parcel. The request needs tracking data, including the carrier and tracking number, and it must reference the correct payment. Store the Hyperswitch payment identifier against the order at authorization time, and confirm which identifier each provider's Fulfillment flow expects. Test that this mapping survives retries, re-authorizations and order edits. Log the request and response for every call so that support can answer a dispute months later from your own records.

Split, partial and delayed shipments are where this design usually breaks. Ask each provider how it handles one order fulfilled across several parcels: whether each shipment needs its own fulfillment call, whether line-item or quantity detail is required, and whether liability attaches per shipment or per order. Decide what happens when a parcel is held, back-ordered or shipped late. Choose whether the call waits for the carrier scan, fires on the first parcel only, or fires after delivery is confirmed, and document that choice. Before go-live, run each case as a test order and keep a report of orders that have not received a fulfillment call.

The liability terms sit in your contracts, not in the integration code. Confirm with Signifyd and Riskified in writing what counts as a qualifying shipment, what evidence they require, the deadline for submitting it, and how they treat orders that never receive a fulfillment signal. Ask for the contractual wording and rely on it over the docs summary. Your legal, risk and finance owners should compare those terms with your merchant agreement and chargeback policy, then decide who owns the exception queue for orders with missing or rejected fulfillment calls.

Test every fraud decision path before the first live order passes through Hyperswitch. The plan should cover each action the FRM workflow can return, because a path that was never exercised is the one that fails quietly in production. For cards, the post-authorization flow has four outcomes to exercise: continue to accept, halt on decline, approve on review and decline on review. For non-card payment methods, only the pre-authorization flow applies, and the test is that an accept decision lets the payment continue. Build one test case per outcome, with a named test order that is expected to produce that outcome, and record the request and response for each.

Next, test the webhook path that brings provider decisions back into Hyperswitch. Hyperswitch verifies Signifyd webhooks with HMAC-SHA256, and Riskified signs its requests with a secret token. For each provider, send a webhook with a deliberately wrong signature and confirm Hyperswitch rejects it and does not change the payment state. Then replay a valid webhook that was already processed and confirm the second delivery does not create a duplicate decision or a second state change. Also confirm that a webhook for an unknown payment is handled safely. Ask each provider how it retries deliveries and whether it signs retries, because your replay tests should match real retry behavior.

Test the Fulfillment call with a sample shipment, since the Hyperswitch docs for both Signifyd and Riskified state that chargeback liability shift requires Fulfillment to be called after shipment. Create a test order, mark it shipped with a tracking reference, and confirm the Fulfillment request reaches the provider with the fields it expects. Check the provider side as well, because a request that Hyperswitch sends successfully is not proof that the provider recorded the shipment. Test the case where Fulfillment is called before the shipment is confirmed, and decide in advance whether your order flow should block that call or retry it.

Test the RecordReturn path with a return on a test order that was previously fulfilled. Confirm that the return is recorded with the provider and that the payment state in Hyperswitch matches what the provider reports. Include a partial return in the plan, since the amount and item data sent to the provider affect how returns are interpreted. Note that a hosted Hyperswitch sandbox exists for testing the Hyperswitch side of these flows. Before you schedule any of these tests, confirm with Signifyd and Riskified whether each offers a sandbox or test mode for your account, what test orders they accept, and whether their decisions in test mode match production behavior. Where a provider has no sandbox, agree in writing with your fraud team how test traffic will be limited and labeled, so that no live customer order is held or declined by accident.