>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3614344. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !33 >>> <p>Reconciling an abandoned Worldline checkout records the payment failed. Letting the expiry sweep write the same non-event off without reconciling records it expired. Which of the two a site gets depends on the reconciliation budget and on whether the provider answered, not on anything the payer did.</p> <h3>What happens</h3> <p>A payer is sent to the hosted checkout and never completes it: they close the tab, or the session lapses. No card is ever entered, so Worldline creates no payment at all. The hosted checkout ends in status CANCELLED_BY_CONSUMER, which is the only status Worldline has for this. There is no separate expired status.</p> <p>Two paths then disagree about what to record:</p> <ul> <li>Reconciliation runs, from the return route or from the reaper with budget left. <code>WorldlinePaymentFinalizer::resolveFromProvider()</code> fetches the hosted checkout and calls <code>finalize()</code> with the created payment, which is NULL. <code>finalize()</code> asks <code>WorldlineGateway::paymentAccepted()</code>, false, then <code>paymentCancelledByConsumer()</code>, which needs a created payment and so is false too, and falls through to <code>fail()</code>.</li> <li>Reconciliation does not run, because <code>reconcile_batch</code> is 0, or the run spent its budget and the grace period has passed, or the provider could not be reached. <code>PaymentManager::expireDue()</code> writes expired.</li> </ul> <h3>Why failed is the wrong answer</h3> <p>No money was ever attempted. A real decline or error always produces a created provider payment in the REJECTED status, and that reaches <code>fail()</code> through the other branch. So the no-created-payment case never means failure, and recording it failed puts a routine abandonment in the bucket an operator is meant to investigate, and in the bucket a failure-rate report counts.</p> <p>It also puts Worldline out of step with every other gateway. <code>PaymentGatewayBase::reconcile()</code> answers NothingHappened, so the same abandonment on the manual or the simulator gateway is recorded expired.</p> <h3>Two smaller things fall out of the same line</h3> <ul> <li>Because <code>finalize()</code> always resolves the payment, <code>resolveFromProvider()</code> can never return NothingHappened for a hosted checkout it successfully fetched. That branch, and the notice naming the hosted checkout status, are unreachable.</li> <li>The hosted checkout status is fetched on every reconciliation and used for nothing except that unreachable log line.</li> </ul> <h3>Proposed resolution</h3> <p>Decide the no-created-payment case from the hosted checkout status and the payment deadline, and never fail it:</p> <ul> <li>The checkout is still open, so nothing final has happened: report NothingHappened and leave the payment pending. The caller deadline decides, exactly as it does for every other gateway.</li> <li>The checkout has ended with no payment created and the deadline has passed: record it expired. Worldline cannot tell a lapsed session from a cancelled one, but the deadline can.</li> <li>The checkout has ended with no payment created before the deadline: the payer cancelled, so record it cancelled, which is what <code>cancelPending()</code> already exists for.</li> </ul> <p>A created payment keeps exactly the behaviour it has today: accepted is recorded, CANCELLED is a cancellation, anything else is a failure. <code>finalize()</code> can then take a non-nullable created payment, since the webhook, its only other caller, already returns early when there is none.</p> <p>Prose to sweep in the same commit: the webhook not-configured warning says payments whose payer does not return will settle only when the expiry sweep asks the provider, which today means recorded failed, and the state documentation describes neither the cancelled nor the expired outcome for an abandoned checkout.</p>