Skip to content

fix(payments-syncs): Support payments sync on async resolution paths - #5982

Open
osmarluz wants to merge 2 commits into
mainfrom
fix/support-payments-sync-on-async-resolution-paths
Open

fix(payments-syncs): Support payments sync on async resolution paths#5982
osmarluz wants to merge 2 commits into
mainfrom
fix/support-payments-sync-on-async-resolution-paths

Conversation

@osmarluz

@osmarluz osmarluz commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

Context

Payments that reach succeeded through a provider webhook (3DS/SCA flows, async off-session confirmations, recovery of a payment missing in the database) were never synced to accounting providers: the sync job was only enqueued from the synchronous charge path and manual payments. The invoice would show up in NetSuite/Xero with no payment applied against it.

Description

Enqueue Integrations::Aggregator::Payments::CreateJob when a payment reaches succeeded in the Stripe, Adyen and GoCardless webhook settlement paths, reusing the should_sync_payment? guard from the synchronous path.

Duplicated provider webhooks can enqueue concurrent syncs for the same payment, so the sync in Integrations::Aggregator::Payments::CreateService is now serialized with a payment-scoped advisory lock (new LockService): the already-synced check runs under the lock, so the payment cannot be created twice in the accounting provider. A job that fails to acquire the lock is a duplicate and is discarded as a no-op — the lock holder and its retries own the sync.

@osmarluz
osmarluz requested a review from ancorcruz July 21, 2026 10:26
return result if payload.integration_payment

throttle!(:netsuite, :xero)
LockService.call(payment:, timeout_seconds: 0, transaction: false) do

@osmarluz osmarluz Jul 21, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

timeout_seconds is 0 here because we don't care about waiting and retrying (if the lock is taken, another process is already syncing this same payment, so this caller can safely bail and let the holder finish)

deliver_webhook if payable_payment_status.to_sym == :succeeded
if payable_payment_status.to_sym == :succeeded
deliver_webhook
Integrations::Aggregator::Payments::CreateJob.perform_later(payment:) if payment.should_sync_payment?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

have you consider if this work for payment gated subscriptions? should_sync_payment? checks if invoice is finalized, won't it be 'open' for payment gated subs?

deliver_webhook if payable_payment_status.to_sym == :succeeded
if payable_payment_status.to_sym == :succeeded
deliver_webhook
Integrations::Aggregator::Payments::CreateJob.perform_later(payment:) if payment.should_sync_payment?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the same applies here.

deliver_webhook if payable_payment_status.to_sym == :succeeded
if payable_payment_status.to_sym == :succeeded
deliver_webhook
Integrations::Aggregator::Payments::CreateJob.perform_later(payment:) if payment.should_sync_payment?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants