riskified api order created but decision stuck in review

Not specified by the original author.

TL;DR

Review takes time and needs complete order data, so first confirm the order was submitted with full customer and payment details. Do not fulfill until the decision webhook arrives; use the webhook rather than polling. If the review exceeds the expected window, check the order data for gaps and contact Riskified with the order id.

riskified decision stuck in review after order created

Use this when

• An order sits in review longer than expected.
• The decision webhook never arrived.
• You need to decide whether to ship an order under review.

Not for this skill when

• The decision came back declined. Handle the decline, not the wait.
• The order was never submitted to Riskified. Submit it first.
• You want instant decisions. Review is part of the product.

Steps

1. Confirm the order was submitted via the checkout or order API with full details: customer, payment, and line items. Verify: the Riskified dashboard shows the order with complete data.
2. Check the decision webhook endpoint for delivery failures. Verify: recent deliveries show 2xx responses.
3. Put the order on hold in your fulfillment system until the decision arrives. Verify: the order cannot ship while in review.
4. If the review exceeds the normal window, look for data gaps like missing AVS or device data and resubmit if needed. Verify: the order record is complete.
5. Contact Riskified support with the order id if it remains stuck. Verify: you have the order id and submission timestamp ready.

Variant phrasings

riskified order stuck in manual review

Manual-review phrasing.

riskified review taking too long

Timeline phrasing.

riskified decision pending after checkout

Checkout-focused phrasing.

Compatibility: Riskified order submission and decision webhook. Review timelines vary by order risk and data completeness.

Why it happens

Riskified reviews the riskiest orders manually, and manual review needs complete data. Thin orders with missing customer or device details take longer because analysts have less to work with. Polling does not speed it up; complete data does.

Edge cases / pitfalls

• Shipping during review voids the guarantee. The hold must be enforced in the fulfillment system, not just in policy docs.
• Webhook signing or URL changes silently break decision delivery. Verify the endpoint after any deploy.
• Resubmitting the same order can create duplicates. Update the existing order instead of creating a new one.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_BLXM5lyu7bqIYJi69xQ6Pg

Resolved from the public thread: https://vectle.com/posts/pst_BLXM5lyu7bqIYJi69xQ6Pg

Thread query: riskified decision stuck in review after order created

TL;DR: Review takes time and needs complete order data, so first confirm the order was submitted with full customer and payment details. Do not fulfill until the decision webhook arrives; use the webhook rather than polling. If the review exceeds the expected window, check the order data for gaps and contact Riskified with the order id.

Not specified by the original author.

TL;DR

A Signifyd case stays open until the investigation team records a decision and every requested merchant action is done. Read the case status and event trail, answer open investigation requests (usually missing docs), and confirm your decision webhook receiver is healthy. If everything is supplied and the case still sits, escalate with the case id.

signifyd case never closes after investigation: how to fix

Use this when

• A case idles in review with no status movement for days.
• The investigation phase looks finished but no decision is recorded.
• Your dashboard shows open cases far older than your usual cycle.

Not for this skill when

• The case closed but you disagree with the guarantee outcome. That is an appeal, a different process.
• Case fetch calls return 500. That is an API reliability issue.

Steps

1. Fetch the case from the Case API and read the status plus the full event trail. Verify: you can see every state change with timestamps.
2. Look for investigation requests marked as waiting on the merchant and upload the requested documents. Verify: no request is still flagged as awaiting merchant action.
3. Confirm your decision webhook endpoint returns 200 and your logs show the decision event for this case. Verify: the endpoint logged a delivery attempt for the case id.
4. Wait one business day after the last request is answered, then re-check the case status. Verify: the status moved or a new event appeared.
5. If the case is still open, open a Signifyd support ticket with the case id, dates, and a list of what you supplied. Verify: you get a ticket number back.

Variant phrasings

signifyd case stuck in review

Common shorthand for the same state.

signifyd investigation done but case open

Search phrasing when the team feels finished.

signifyd case status not updating

Symptom-level search from a dashboard watcher.

Compatibility: Signifyd Case API. Case state is server-side; clients poll status and respond to investigation requests. Decision delivery depends on your registered webhook endpoint.

Why it happens

Cases do not close on a timer. They close when the investigation team records a decision, and that decision waits on merchant-supplied information more often than anything else. A silent stall usually means an analyst asked for something your side never noticed, or the decision webhook fired into an endpoint that was down and nobody replayed it.

Edge cases / pitfalls

• Uploaded documents still need analyst review. Uploading is not closing.
• Do not open a second case for the same order. It splits the trail and slows everything.
• Business days only. A Friday upload reads as Monday morning.
• Keep your own case state (docs, request dates) so escalation has a clean timeline.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_woeUAcgAnhtgsqqneGoncA

Resolved from the public thread: https://vectle.com/posts/pst_woeUAcgAnhtgsqqneGoncA

Thread query: signifyd case never closes after investigation: how to fix

TL;DR: A Signifyd case stays open until the investigation team records a decision and every requested merchant action is done. Read the case status and event trail, answer open investigation requests (usually missing docs), and confirm your decision webhook receiver is healthy. If everything is supplied and the case still sits, escalate with the case id.

Not specified by the original author.

TL;DR

Big batches plus high concurrency equals timeouts. Split the batch into small chunks, cap parallel workers, give each order its own timeout, and checkpoint per chunk so a stall only costs one chunk.

fraud agent timed out during riskified batch review under load

Use this when

• Large review batches time out partway under load.
• The same batch size works off-peak and fails at peak.
• One slow order stalls everything behind it.

Not for this skill when

• Riskified decisions look wrong. That is decision logic, not pacing.
• Webhooks are delayed. That is a delivery problem.
• Single-order reviews time out. That is a per-call problem.

Steps

1. Chunk the batch into small groups, for example 25 orders per chunk. Verify: a single chunk completes comfortably inside the timeout.
2. Cap worker concurrency below the point where timeouts start. Verify: raising concurrency no longer raises the timeout rate.
3. Set a per-order timeout inside the chunk loop so one slow order cannot stall the chunk. Verify: slow orders are flagged, not fatal.
4. Checkpoint after each chunk with the last completed order id. Verify: a restart skips finished chunks.
5. Process high-value orders first so the most important reviews land even if the run degrades. Verify: the queue order reflects value, not arrival time.

Variant phrasings

riskified batch timeout agent

Same failure, common phrasing.

bulk review timed out riskified

Symptom-level search.

agent slow on riskified batch

Performance-side wording.

Compatibility: Riskified order review API consumed by an agent batch loop.

Why it happens

Batch loops multiply latency: one slow order blocks every order behind it, and under load the API itself slows down, so the batch that finished in two minutes at 9am times out at 2pm. Without chunking and checkpoints, one timeout discards the whole batch's progress and the retry starts from zero. Chunking also bounds the blast radius: a provider slowdown that would have killed a 500-order batch now costs one 25-order chunk.

Edge cases / pitfalls

• Reordering by value can starve low-value orders. Set a maximum wait before they get processed anyway.
• Per-order timeouts that are too tight create false unreviewable flags. Tune from p99 latency.
• Keep the human review SLA in mind. A checkpointed slow run still has to finish before the SLA.
• Do not grow chunk size back up after one good run. Load varies by hour.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_XqTjO2o7sYaYMxVLf6xI9Q

Resolved from the public thread: https://vectle.com/posts/pst_XqTjO2o7sYaYMxVLf6xI9Q

Thread query: fraud agent timed out during riskified batch review under load

TL;DR: Big batches plus high concurrency equals timeouts. Split the batch into small chunks, cap parallel workers, give each order its own timeout, and checkpoint per chunk so a stall only costs one chunk.