CacheFlow payment integration for ecommerce

CacheFlow is configured with a primary acquirer and one or more fallback acquirers. When auth fails or times out on the primary, CacheFlow automatically routes the retry to a secondary acquirer without the customer seeing an error or re-entering payment details.

CacheFlow-issued tokens are specific to CacheFlow's vault. If you migrate to a different orchestrator, those tokens cannot be reused and customers must re-enter cards or you must maintain a legacy vault in parallel during transition. Plan token migration as part of any payment provider change.

Routing decisions should align with fraud risk models; distributing transactions across acquirers spreads fraud liability but also spreads risk exposure. You should define routing rules in consultation with your fraud team and monitor chargebacks by acquirer to ensure the strategy is working.

CacheFlow publishes daily settlement files that summarise captured transactions, refunds, fees and payouts by acquirer. ERP imports and matches these records against commerce transactions. If timing windows differ (e.g., capture-to-settlement lag), reconciliation may require manual adjustment lines until settlement balances.

During CacheFlow outage, the fallback depends on your architecture: if checkout can re-route directly to a backup acquirer, transactions may continue; if not, checkout must queue or pause. Define and test the fallback before launch so you know what happens to customers and ERP order flow.

CacheFlow allows you to define a single 3DS policy (always trigger, trigger on risk score, never trigger) and applies it consistently across all acquirers. Changing the policy requires updating CacheFlow config and should be tested in staging to avoid unexpected authentication friction.

CacheFlow tokens are vendor-specific and region-agnostic within CacheFlow's infrastructure. You can reuse tokens across multiple commerce instances if they share the same CacheFlow tenant, but token portability depends on CacheFlow's architecture and your contract.

CacheFlow receives chargeback notifications from payment networks and forwards them to commerce and ERP via API or daily report. Customer service owns investigation and evidence submission; finance owns the P&L impact and reconciliation. Define clear ownership and escalation paths before launch.

Monitor transaction volume and decline rates by acquirer, auth latency, tokenisation vault size and failed refunds. Set up alerts for spikes in declines, acquirer unavailability, settlement delays or mismatched transactions so operations can respond before customers or finance notice.

CacheFlow has timeout thresholds; if an acquirer does not respond within the configured window, CacheFlow retries or fails over to a secondary. If CacheFlow itself is slow or unreachable, timeout behaviour depends on your checkout fallback configuration - ensure this is tested and documented.

Payment operations or finance typically owns routing rules in consultation with fraud and compliance teams. Rules should be reviewed quarterly or when acquirer contracts change, and any material change should be tested in staging and rolled out gradually to monitor impact on decline rates and cost.

Transactions in progress when a rule changes may be routed under old or new rules depending on timing. Have a rollback plan that includes how to handle partial or ambiguous transactions, and ensure monitoring and exception handling are in place so customer service and finance can trace outcomes.

CacheFlow charges per transaction or by volume; this cost should flow into ERP via settlement detail or as a separate fees feed. Define how payment processing fees are allocated to orders and channels so margin reporting and P&L are accurate.

CacheFlow supports configurable policies (3DS, velocity limits, currency handling) but does not automatically enforce regional compliance rules. You must define and maintain compliance rules in CacheFlow and verify that your configuration meets local requirements (PSD2, local network rules, etc.).