Payment Syncing

JPM sends a status callback to webhooks.floatme.io whenever a payment’s status changes. The webhook handler decouples receipt from processing by immediately enqueuing the event to SQS.

The jpm-webhook-processor looks up the payment record by JPM’s endToEndId (stored as confirmation_id), then writes the updated status. If the status is RETURNED or REJECTED, the return_code field is also set, which the downstream Kinesis pipeline uses to determine blocklist action.

See JPM Integration for the full JPM status set and return code mappings.

Not all ACH status changes arrive via webhook. The check-ach pipeline resolves outstanding ACHSENT records daily: JPM payments are polled against JPM’s status API, while Usio payments are auto-completed once they’ve aged past the 3-business-day gate (returns are handled separately by the daily Usio ACH-returns sweep that runs 30 minutes earlier).

The scheduler filters at the DynamoDB source on a single criterion so it doesn’t enqueue records the worker would early-return on:

There is no longer a submit_date cutoff: every ACHSENT debit is enqueued regardless of age. The worker applies its own clearing gates (the plaid path clears as soon as a matching settled transaction appears; the JPM/Usio provider path still requires 3 business days), so age filtering is left entirely to the worker.

The enqueue phase fans SendMessageBatch calls across a small goroutine pool (sqsParallelism workers, each handling sqsChunkSize entries), because at peak volume a serial loop of ten-message batches exceeds the 15-minute Lambda timeout. fmsdk’s SendMessageBatch still sub-chunks each worker’s slice into AWS’s 10-entry batches internally.

The check-ach queue uses maxReceiveCount = 1, so a single worker failure sends the message to the DLQ without retry. This prevents duplicate status writes for the same payment.

check-ach-worker also notifies the Transaction Service when a float payment transitions out of ACHSENT, so the transaction record can be updated accordingly.

Usio has no webhook mechanism. A separate sync pipeline polls Usio transaction data and reconciles it against DynamoDB records. There are three CloudWatch schedules feeding the same usio-scheduler Lambda:

The Usio sync covers all four merchant accounts (subscription debit, float debit, float credit, loan accounts). It is the primary reconciliation mechanism for all Usio ACH payments since Usio does not send webhooks.

When a syncing mechanism determines that an ACHSENT payment has settled, it writes the updated payment record. The outcome depends on the new status:

Usio debit/credit tokens can expire. A separate daily job refreshes tokens before they become invalid:

In addition to webhook callbacks, a daily job syncs JPM raw transaction details to a separate DynamoDB staging table:

This sync stores raw JPM transaction data for audit and reconciliation purposes, separate from the payment status updates handled by the webhook pipeline.