ACH Payment Processing Platforms for U.S. Collections and Payouts

ACH payment processing platforms for builders who need execution, not hype#

Start with the outcome, not the feature label. You may need a setup that collects money in and sends money out over the U.S. banking network, not just a generic bank-transfer option. In practice, that often means ACH debits for collections and ACH credits for payouts, with controls your product, engineering, and finance teams can run in production.

Define the money movement#

Define your flow clearly: inbound pulls, outbound pushes, or both. ACH supports both credit and debit payments, and the ACH Network reaches U.S. bank and credit union accounts.

Write one sentence that states who pays whom and whether each move is a debit or a credit. If you cannot do that yet, you may not be ready to compare providers. ACH is an electronic money transfer between banks and credit unions over the Automated Clearing House network. Provider differences show up in how you initiate, track, and reconcile that transfer.

Set timing expectations early#

Set speed expectations before anyone promises "fast bank payments." ACH timing varies. Some payments clear quickly, including same day during business hours, while others can take days to complete.

Same Day ACH is the faster ACH option, designed for same-business-day delivery. It settles three times daily, and each payment can be up to $1 million. ACH credits can settle same day, next banking day, or in two banking days, so these are different timing options rather than one guaranteed timeline.

Build your customer promise around your real operating model: submission timing, bank cutoffs, approvals, exception handling, and delay messaging. If fast payouts are central to your product, read this alongside Same-Day ACH for Platforms: How to Speed Up Contractor Payments Without Wire Transfer Fees.

Assign owners before you shop#

Set ownership before procurement locks in your choices. Product can define customer timing promises, engineering can validate transaction-state and failure-handling needs, and finance can define reconciliation for posted transactions, returns, and timing differences.

Use a cross-functional launch checkpoint. Each owner should be able to state what "ready to launch" means for their part. If you need both collections and payouts, treat that as a day-one requirement so your implementation is built for operation, not a short-lived demo.

If you want a deeper dive, read AI in Accounts Payable: How Payment Platforms Use Machine Learning to Process Invoices Faster.

What an ACH platform actually does in a platform stack#

ACH is the rail, not the product. The rail moves batched electronic credits and debits across the U.S. banking network. The platform layer is what your team uses to initiate transfers, handle status changes, and run operations without guessing.

Separate the rail from the product layer#

Separate the transfer rail from platform behavior. On the rail, money moves as credits and debits. In your product, that turns into operational work:

• collect a debit your team can reconcile in your own AR workflow
• send a credit payout to a bank account
• run recurring authorized ACH debits for repeat payments
• handle Auto-pay failures with retries or customer notifications

If a vendor only shows generic bank-transfer screens but cannot show status and exception paths for these jobs, treat that as a real risk.

Check orchestration, status, and retries#

The value is in orchestration, not the mere existence of ACH. You need asynchronous events, retry behavior, and clear transfer states so engineering can respond to failures and finance can reconcile posted versus pending activity.

Use a simple verification test: ask for transfer lifecycle and webhook behavior in writing. In Dwolla's documented flow, your endpoint must return a 200-level response within 10 seconds or delivery is treated as failed and retried. After 400 consecutive failures and 24 hours since the last success, the webhook subscription is automatically paused. Miss those events, and your operational visibility degrades quickly.

Optimize for one operational surface#

If you need both collections and payouts, optimize for one operational surface, not just the lowest transfer cost. Shared controls across inbound debits, outbound credits, recurring collections, and exceptions usually matter more in day-to-day execution.

Also confirm event-history retention in the API. Stripe documents 30 days for event retrieval. If your audit trail or close process needs longer, store your own event log from day one.

For a step-by-step walkthrough, see Webhook Payment Automation for Platforms: Production-Safe Vendor Criteria.

What to prepare before you evaluate vendors#

Write your requirements before demos so you are testing operational fit, not reacting to polished bank-transfer screens. Put them in a short packet the team can review together.

Build a requirements packet#

Start with a requirements packet that fixes your operating assumptions in writing. Include expected monthly transaction count, average and high-end ticket sizes, inbound versus outbound mix, and payout cadence by use case. If any payment could approach the Same Day ACH $1 million per payment limit, flag it up front.

Define timing as concrete cutoffs, not labels like "fast." For Same Day ACH planning, include the current-day milestones listed on the FedACH processing schedule at 10:30 a.m. ET, Noon ET, 1:00 p.m. ET, 4:45 p.m. ET, 5:30 p.m. ET, and 6:00 p.m. ET so late-day windows are covered. Close the packet with ERP integration requirements in plain English: what data must sync, where it lands, and who uses it. Verification point: finance and engineering should both agree that this packet describes the same money-movement reality.

Define controls and exception ownership#

Define controls before you compare UI. Specify who can create, approve, release, and override payments or debits, who owns reconciliation, and who handles incidents when flows stall.

Make admin override policy and audit treatment explicit. Also define exactly how invoice auto-application should work in your process, what reference data is required, and who owns exceptions when matching fails. Treat receipt matching as workflow-specific, not something that will be uniform across platforms and ERPs. Failure mode to avoid: unmatched receipts fall into a manual queue with no owner after go-live.

Lock engineering non-negotiables#

Set engineering non-negotiables in writing: documented webhook behavior, idempotent retry support, and lifecycle coverage that includes ACH returns and reversals.

Ask each vendor to provide retry and event-query limits explicitly. One published model retries undelivered webhook events for up to three days and only returns events from the last 30 days when queried. Do not assume every provider behaves that way. If idempotency keys are supported, capture those constraints too. One documented API supports keys up to 255 characters and may prune them after at least 24 hours. Use Nacha Operating Rules as the detailed reference when validating ACH data elements and rule coverage.

Gather proof artifacts before signing#

Gather proof artifacts before signing, even if your team is lean. Keep a minimum pack with:

• current security evidence, ideally the latest SOC 2 examination report
• written support terms, including baseline coverage and escalation options
• a tracked list of unresolved questions on fees, volume thresholds, contract limits, and implementation dependencies

This keeps unknowns visible and separates verified capabilities from vendor claims before signing.

You might also find this useful: SOC 2 for Payment Platforms: What Your Enterprise Clients Will Ask For.

Decide your ACH scope before you compare providers#

Decide scope before demos: define whether each flow needs ACH debits, ACH credits, or both, then compare providers against that map.

Map each flow to debit, credit, or both#

Map every money movement to its rail direction first. In ACH, collections are debits and disbursements are credits, so this should shape your shortlist before any UI comparison.

Write one line per flow and label it debit, credit, or both for things like invoice collection, subscription renewal, contractor payout, or payout correction. If you need both Accounts Receivable and payout orchestration, say that explicitly in your requirements packet. Verification point: require status coverage to be shown separately for ACH debits and ACH credits. "We support ACH" is not enough.

Rank payout depth correctly#

If contractor payouts are business-critical, put payout lifecycle depth above billing polish. Detailed payout states, exception handling, and release controls matter more than polished front-end invoicing.

Status certainty is not uniform across providers or flow types. Stripe's ACH Direct Debit documentation, for example, says success or failure acknowledgement can take up to 4 business days, which can affect release decisions tied to funds certainty.

Ask for the full debit lifecycle and full payout lifecycle in writing, including reversals and failures. If payout exceptions are vague or handled outside controlled queues, treat that as a risk for payout-heavy models.

Weight recurring behavior when it matters#

If your revenue behaves like subscriptions, weight recurring behavior above one-time invoice UX. ACH supports both recurring and one-time patterns, so your scoring should reflect your real mix.

Validate how recurring schedules are created, changed, paused, and audited. Do not stop at whether recurring is "supported." If recurring flows touch consumers, preauthorized electronic fund transfers can trigger Regulation E notice obligations. In some cases, that includes notice at least once every 60 days.

BILL's ACH page is a useful fit signal because it markets both payables and receivables coverage, along with recurring and invoice auto-pay. Still, treat that as a signal, not proof that your edge cases are covered.

Set timing by workflow#

Set timing by workflow, not by vendor marketing labels. Reserve Same Day ACH for genuinely urgent flows, and keep planned non-urgent volume on standard or future-dated ACH.

Same-day processing depends on transmission deadlines, and cutoff mechanics are operator-driven. Keep the hard guardrails in scope: Same Day ACH applies to eligible payments up to $1 million, transactions above $1,000,000 are excluded, the expanded submission window runs to 4:45 p.m. ET, and interbank settlement in that third window occurs at 6:00 p.m. ET.

Use those constraints when you write SLA and cutoff promises. For deeper speed tradeoffs, see Same-Day ACH for Platforms: How to Speed Up Contractor Payments Without Wire Transfer Fees.

Related: Guide to Bulk Payment Processing: How Platforms Send Thousands of Payouts in a Single Run.

Compare providers with a weighted scorecard your team can defend#

Use one weighted scorecard for every vendor, then apply an evidence penalty before final ranking. Operational fit should carry the most weight, and unsupported claims should stay unknown.

Score the work your team will run#

Score the work your ops and finance teams will actually run after launch.

If you are payout-heavy, shift weight from invoice handling to payout coverage. If you are invoice-heavy and recurring-debit heavy, increase reconciliation and auto-application weight.

Verification point: every scored cell needs a proof artifact. If a claim is not supported by docs, support pages, or contract language, score it unknown.

Build the evidence table first#

Build one side-by-side evidence table first, then score from that table.

Read this table as evidence strength, not brand strength. BILL shows payables-plus-receivables signals, GoCardless shows strong documented ACH debit collection and invoice-linked integration signals, and Stripe shows the clearest documented invoice matching and retry behavior in this evidence set.

Penalize weak evidence#

Apply an evidence-quality penalty before you total the scores. Vendor docs and support docs are usable, but they are still vendor-authored. Ranking articles are secondary. Anecdotes are directional only.

HighRadius is a vendor-hosted ranking format, so use it for discovery, not proof. Forbes is useful as a cross-check because it discloses methodology across 18 providers and 54 decision factors. Affiliate-disclosed comparisons can still help you build diligence questions, but they should not increase a provider score without independent verification.

Decision rule: if reconciliation depth is weakly evidenced, cap that provider at shortlist until they provide exact docs, product screens, or contract language.

Failure mode to watch: posted pricing or anecdotal reviews can pull teams off course. A single-user complaint (for example on Trustpilot) or a broad vendor trust claim (for example on CheckIssuing) belongs in a watch list, not in core capability scoring.

If your scorecard prioritizes payout status depth, idempotent retries, and batch operations, benchmark those requirements against Gruv Payouts.

Design the money movement architecture and control points#

Before you sign, lock the architecture so your team can always answer three questions: what stage a payment is in, who can release it, and what finance should post against Accounts Receivable.

Map the flow as distinct states#

Treat ACH as a batch network, not an instant-confirmation rail. Because ACH includes batching, operator processing, and settlement, submitted and settled should never be the same status in your ledger or dashboard.

Model one internal gate before network submission, then the source-backed ACH milestones after that. ACH can push and pull funds, so use the same state model for debit collections and credit payouts, even when the business logic differs.

The batched and submitted state is critical. If your product only shows pending until paid, ops cannot tell whether an item missed submission, is with the operator, or is simply late.

A practical posting rule is to attach the payment to the invoice at initiation, but clear the open receivable only after settlement. Settlement is typically one to three business days, and ACH does not currently settle on weekends or federal holidays.

Put release and exception controls before submission#

ACH rules do not define your internal approval chain, so you need to define it explicitly. Separate at least three responsibilities: who creates the payment, who approves it, and who releases it to the provider or bank.

For debit collection and recurring ACH runs, make authorization evidence a release gate. Originators must maintain receiver authorization and provide a copy when requested. Consumers must receive a copy for their records. Before launch, confirm that your team can retrieve authorization from the payment record itself.

Set a hard exception rule: if a recurring run looks delayed, do not automatically re-run the batch. First confirm whether the item is still at validation, already batched, in operator processing, or returned.

Be careful with reversals. Improper reversals are explicitly restricted, so a reverse payment action should not become a routine correction path. Your exception policy should separate consumer and non-consumer handling because return treatment differs. For improper-reversal returns, that includes R11 consumer handling with a 60-day return timeframe upon consumer claim and R17 non-consumer handling with a 2-day return timeframe.

If you offer Same Day ACH, add a release gate for amount limits. The current Same Day ACH limit is $1 million per payment, effective March 18, 2022, so payments above that amount should be blocked from the same-day path.

Instrument aging, ownership, and alerts#

Track returns as first-class statuses, not side notes. Your monitoring should cover both forward-processing milestones and return milestones. Use clear ownership splits:

• Payments operations owns visibility from initiation through settlement or return.
• Finance and AR own settlement matching, open-item clearing, and unresolved returns.
• Missing status updates are integration incidents, not AR exceptions.

For same-day monitoring, use FedACH reference windows of 10:30 a.m. ET -> 1:00 p.m. ET, 2:45 p.m. ET -> 5:00 p.m. ET, and 4:45 p.m. ET -> 6:00 p.m. ET, and include return-processing milestones. For items not eligible for same day, settlement occurs at 8:30 a.m. ET on the applicable future business day.

Keep alerting simple: alert when an item ages past its expected next milestone, not only when it is fully overdue. If a same-day payout remains batched after the intended window, route it to payments ops. If a settled debit is not posted cleanly to AR, hand it to finance that same day.

Need the full breakdown? Read Continuous KYC Monitoring for Payment Platforms Beyond One-Time Checks.

Implement in phases with explicit launch checks#

Launch in phases, not all at once: first prove one clean ACH lane, then harden controls, then scale. Because ACH is a batched U.S. banking network, operational discipline usually matters more than adding features early.

Start with one lane and fixed cutoffs#

Start with one business line and one flow type: collections or payouts. Keep Phase 1 to standard ACH or future-business-day processing, with one internal release cutoff and no faster-delivery promise you cannot verify from submission to settled-or-returned outcome.

Your first go-live proof should be strict and easy to audit. For live samples, ops should be able to show initiation, approval, submission timestamp, and final status from one record. Finance should confirm that the invoice or payout liability is linked at initiation and cleared only at settlement. If items still disappear into a generic pending state, Phase 1 is not complete.

Add retries and recurring features behind flags#

In Phase 2, treat retries and recurring features as risk controls, not just UX upgrades. Define retry rules that distinguish pre-submission failures from post-submission outcomes such as returns, and avoid blind retries of in-process batches.

Roll out Auto-pay and recurring ACH transfers behind feature flags by segment or cohort. For consumer debits, preauthorized electronic fund transfers may be authorized only by a writing signed or similarly authenticated by the consumer, so authorization evidence should be easy to retrieve from the payment record. Support should also be ready for stop-payment requests made at least three business days before a scheduled transfer. Recurring consumer flows should be reviewed for Regulation E notice obligations when transfers occur at least once every 60 days.

Expand segments only after timing policy is explicit#

Scale to additional segments one at a time, and only add faster settlement where the business case justifies the complexity. ACH credits can be scheduled for same-day, next-banking-day, or two-banking-day settlement, while ACH debits cannot be settlement-dated more than one banking day ahead.

If you enable Same Day ACH, enforce eligibility gates: on-time submission, no future date, and exclusion of IAT, ENR, and items above the $1,000,000 per-payment cap, effective March 18, 2022. Tie release operations to FedACH same-day transmission deadlines at 10:30 a.m. ET, 2:45 p.m. ET, and 4:45 p.m. ET. If you cannot reliably hit those cutoffs, keep that segment on next-day or standard processing. For more on that tradeoff, see Same-Day ACH for Platforms: How to Speed Up Contractor Payments Without Wire Transfer Fees.

Gate every phase with written go-live evidence#

Before each phase goes live, use written internal checks for reconciliation quality, support readiness, and rollback planning. Define your own pass criteria in advance, including settlement posting accuracy, return capture, and no orphaned records between provider events and your ledger.

Support readiness should cover delayed settlement, returns, and recurring debit cancellation handling, plus a clear process for retrieving authorization evidence without engineering help. Rollback should clearly separate actions such as stopping new submissions, disabling new recurring enrollment, or pausing release of already validated batches, because items already submitted may require return/NOC exception handling rather than a simple reset.

Related reading: Device Fingerprinting Fraud Detection Platforms for Payment Risk Teams.

Make reconciliation and finance handoff boring and reliable#

Aim for a handoff your team does not have to think about: every ACH item should have a clear lifecycle status, a clear owner, and a clear accounting outcome without side spreadsheets.

Define one operational record and one accounting record#

Define one system of record for payment status and one for accounting. ACH is a batch, store-and-forward rail for both collections and disbursements. Keep lifecycle ownership in your payments stack until the outcome is final. Keep posted Accounts Receivable and payout liability ownership in your ERP or ledger.

Set a handoff cadence between payments ops and finance, plus a close-period checkpoint. For collections, hand off settled cash, unapplied cash, and return exceptions. For payouts, hand off liability population, released amounts, and breaks between release and bank movement. If you use Stripe, treat payout mode as a reconciliation design choice: automatic payouts preserve transaction-to-payout linkage, while manual payouts put that reconciliation burden on you.

Verification checkpoint: trace a live sample from initiation to final status, bank-reconciliation output, and ERP posting. If the explanation still depends on engineering intervention, ownership is not clear enough.

Build a reconciliation table before volume grows#

Build a state table early so pending does not become a catch-all. Each state should define its source event, owner, internal SLA, and recovery action.

Verify accounting behavior with real exceptions#

Test accounting behavior with exception paths, not just exact matches. Oracle AutoCash is a useful model because it explicitly handles partially applied receipts by leaving residual amounts Unapplied or moving them On-Account. Your system can use different labels, but the rule should be explicit before go-live.

Validate integration depth, not just integration presence. Stripe documents webhook-event handling for its NetSuite connector and supports accounting integrations like QuickBooks. BILL documents integration paths including export/import fallback. Confirm action-by-event mappings, required fields, and fallback file formats in sandbox runs.

Verification checkpoint: exact match, short pay, overpay, and returned debit should route to the expected queue or ledger account without ad hoc remapping.

Set month-end rules before the first close#

Define unresolved-item handling before your first close. Keep an unresolved-items log with aging, owner, next action, and carry-forward treatment, and set your aging buckets in advance, for example a 1 to 30 days past due bucket. Some systems support four- or seven-bucket structures.

Do not force false finality at close. Exception timelines can differ by context, so keep open returns and disputes visible in the close package. A practical sign-off split is that payments ops confirms statuses and recovery actions are current, while finance confirms posting, exception queues, and bank-reconciliation evidence are complete.

Handle failures, returns, and retries without duplicating money movement#

Assume a retry can duplicate money movement until your records prove the first attempt never entered processing.

Classify the break before you act#

Classify the exception first, then choose recovery:

Common ACH failure causes include insufficient funds, closed accounts, and incorrect account information.

Verification checkpoint: for each exception, capture payment ID, batch or effective date, idempotency key or request ID, latest provider event, and customer-facing state. If you still cannot confirm whether money entered processing, do not retry yet.

Retry only after state and idempotency checks#

Set one recovery rule: retry only with idempotency protection and only after a state check confirms that the prior request did not already create a live payment or reach a submitted state.

Use the return reason to branch next actions:

• R02, R03, R04 (administrative): correct account data before replay.
• R05, R07, R10, R11, R29, R51 (unauthorized): pause automatic re-debit and route to review.

For same-day edge cases, plan for FedACH limits. Derived returns cannot be used for Same Day ACH forward entries on settlement day, so same-day settlement in that scenario requires a return file submission by 4 p.m. ET.

Trigger customer messages from expectation gaps#

Send customer updates when expectations break, not only when a payment reaches final failure.

• Failed Auto-pay: notify on rejection or return, and include amount, date, impact, and required next step.
• Payout delays: notify when expected arrival timing is at risk, including same-day expectations.

In status messaging, keep sent to bank separate from available to withdraw so users can interpret ACH timing correctly.

Common mistakes platform teams make and how to recover fast#

A common costly mistake is choosing by brand familiarity instead of mapping your actual money movement. A practical recovery path is to pause, re-score, and relaunch one flow at a time.

Map your actual money movement before you compare brands#

Do not treat BILL, GoCardless, and Stripe as interchangeable. Their published materials point to different strengths: Stripe documents ACH Direct Debit separately from payouts, GoCardless emphasizes recurring bank-debit collection, and BILL emphasizes AP and AR with accounting and ERP connectivity.

Rebuild your shortlist around your actual mix:

• inbound collections only
• outbound payouts only
• both collections and payouts
• recurring debit, one-off invoice collection, or scheduled payout batches

Verification checkpoint: for each vendor, attach the exact product page or doc that proves support for the required flow. If you cannot point to flow-specific documentation, treat that capability as unverified.

Downgrade weak evidence before it distorts the decision#

Listicles and forum threads can help you discover options, but they are not implementation proof. HighRadius notes that providers have different capabilities, and Reddit's own terms say it does not control or endorse user content.

Use a simple ranking rule: vendor documentation and your own testing outrank roundups and anecdotes. Third-party comparisons are most useful when they show structured criteria, not just a winner.

Pull finance ops into scope before launch#

Under-scoping finance operations can create launch risk. ERP and accounting integration, along with ACH exception handling, should have explicit ownership before go-live.

BILL highlights two-way sync and ERP options, and Federal Reserve guidance describes ACH exception resolution as historically time-consuming when institutions had to resolve cases directly. If finance operations stay out of scope, exception handling and close workflows are more likely to stall after launch.

Relaunch one flow at a time with checkpoints#

Pause the rollout, re-score vendors against your requirements table, and relaunch one flow first. Start with the most business-critical path, then expand only after checkpoints pass.

Before each relaunch, confirm:

• documented support for the specific flow
• status visibility across submission and exception outcomes
• finance handoff for ERP and accounting, plus ACH exception handling

If any step is still based on anecdote rather than proof, do not expand to the next flow.

This pairs well with our guide on Business Process Automation for Platforms: How to Identify and Eliminate the 5 Most Expensive Manual Tasks.

Final decision checklist you can copy into your launch doc#

Use this as a go-live gate. If a provider cannot clear these checks with evidence, you are not ready to launch at meaningful volume.

1. Step 1: Confirm your exact ACH scope first.

Define the first production flow in plain terms before comparing vendors. Decide whether you are launching collections, payouts, or both across the ACH Network, which reaches U.S. bank and credit union accounts. Specify who initiates payment, whether the flow is debit or credit, which business line launches first, and what stays out of scope.

Verification point: your launch doc names the first flow and explicitly lists out-of-scope flows. Red flag: "we support both" without flow-by-flow vendor confirmation.

1. Step 2: Score shortlisted providers with weighted criteria and evidence notes.

Compare providers with explicit criteria and relative importance, then record why tradeoffs beat lowest price when they do. This is how to compare providers without defaulting to brand familiarity or listicle rankings.

For each score, tag evidence quality: product docs, live demo proof, contract language, third-party roundup, or anecdotal claim. Methods differ across publisher lists. One cites 18 providers across 54 factors, while another uses a top-10 format. Useful for discovery, not implementation proof.

Verification point: every high score has a link or artifact. Failure mode: the team assumes ERP integration or invoice matching support, but no one can produce documentation, demo evidence, or connector limits.

1. Step 3: Validate implementation readiness before you move money.

Confirm retry safety, asynchronous status handling, and ownership for failures before launch. Use idempotency keys on creation and retry paths so repeated requests return the same result instead of creating duplicates. Require webhook or event coverage so transaction state is updated from asynchronous outcomes, not just the initial API response.

Verification point: run a staged failure test that retries the same request with the same idempotency key and confirms webhook-driven state updates in your database. Red flag: "just retry" guidance with no duplicate-prevention or final-state handling details.

1. Step 4: Validate finance readiness at the same depth as engineering.

Make sure payment states map cleanly into AR and reconciliation workflows before launch. If you depend on invoice auto-application, validate behavior in your actual accounting path, not only in a general demo. Connector gaps are real. For example, some connectors may not support invoice payment application.

Verification point: finance reviews one end-to-end sample from initiation through reconciliation posting. If ERP integrations rely on matching rules, confirm how match confidence is shown and how low-confidence items are handled. Failure mode: payments settle, but finance is left with a manual exception queue.

1. Step 5: Launch in phases and gate Same Day ACH separately.

Roll out in phases, then enable faster processing only where urgency justifies it. Start with one business line, fixed cutoffs, and standard ACH. Expand only after reconciliation, support handling, and rollback steps are proven in production.

The hard check is eligibility plus timing. Same Day ACH excludes IAT, ENR, and transactions above $1,000,000. FedACH lists current-day settlement windows tied to transmission deadlines, 10:30 a.m. ET to 1:00 p.m. ET, 2:45 p.m. ET to 5:00 p.m. ET, and 4:45 p.m. ET to 6:00 p.m. ET. Confirm the provider cutoff you are actually held to, then set a clear go or no-go rule before enabling faster processing.

Related reading: How Payment Platforms Really Price FX Markup and Exchange Rate Spread.

When your launch checklist is finalized, turn it into an implementation plan with webhook, state-transition, and reconciliation details in Gruv Docs.