← automation
sherpa-api#462 Done · In review ⏱ 2h 3m
Nordic bank direct debit (Autogiro / Betalingsservice)
⎇ auto/api-462-nordic-bank-direct-debit-autogir
Portal localhost:3011Embed localhost:3111API localhost:4011
🔍 iterative-review ✓ (main-pass) 🧪 test:api failed 230 passed · 5 failed · 0 flaky · 12 skipped · report 🧑‍🔬 QA ✅ PASS

Feedback

Pull requests

loading…

QA evaluation

✅ PASS

PASS. Independently drove the live portal (:3011 → API :4011) in a headless browser with an injected CRM session and exercised every acceptance criterion in the real UI. Both Nordic rails are configurable per org (Autogiro SE + Betalingsservice DK shown Active in Settings → Payment Providers); a mandate is created and activated; a recurring premium is scheduled, submitted via the collection batch, and settled; and — the clause that failed QA round 1 — the settled premium reconciles to its policy: the Schedule dialog's new Policy selector links the collection, and after settlement PolicyOrder P100010000191 was promoted pending→active with externalPaymentRef/provider stamped (confirmed both in the Policy column and via API). A failed collection retries to 3/3 then flags with a manual retry. test:api shows 230 passed / 5 failed / 12 skipped, but all 5 failures are pre-existing and unrelated to #462: 06-product-translations and 06-policy-suspension-reinstatement (the documented baseline) plus 02-bulk-renewals, 04-ledger-counts and 05-verify-count (known shared-DB count/ledger pollution from concurrent worktrees, e.g. 198 vs ≤10). The new 09-direct-debit spec passes. No new failures, feature fully usable in the UI → PASS.

6/6 acceptance criteria passed
  • Configure Autogiro (SE) provider per orgPortal Settings → Payment Providers (/settings?tab=payment-providers): 'Autogiro (Sweden)' card present with its toggle data-state=checked and 'Active' label. eval-1.
  • Configure Betalingsservice (DK) provider per orgSame tab: 'Betalingsservice (Denmark)' card present, toggle checked + Active. Also drove a full DK mandate→collection→settle on product 301: created Betalingsservice (DK) mandate (clearing 1234, Danske Bank), activated, scheduled 147 DKK, ran batch → submitted, simulated settled → settled. eval-1, eval-5.
  • Set up a mandate (pending → active)On /products/301/direct-debit created an Autogiro (SE) mandate via the Create-mandate dialog (holder, country SE, clearing 8327, account, Swedbank) → row showed 'pending'; clicked Activate → row flipped to 'active'. eval-3.
  • Recurring premium collected (schedule → run → settle)Schedule-collection dialog → 197 SEK; clicked 'Run due collections' → row 'submitted'; clicked 'Simulate settled' → row 'settled'. eval-2, eval-3.
  • Collected premium reconciled to the policyRound-1 failing clause now works from the UI. The Schedule dialog has a Policy selector; linked the collection to pending policy P100010000191, then ran+settled it via the UI. Collections-table Policy column shows P100010000191 with status badge 'active'. API corroboration: PolicyOrder 8323 went pending→active, externalPaymentRef=AG-COL-3DE4B408, externalPaymentProvider=autogiro. eval-2, eval-3.
  • Failed collection retries and flagsScheduled 283 SEK, then Run + 'Simulate failed' repeatedly: retries advanced to 3/3, status flipped to 'failed', flag indicator shown, manual 'Retry' button offered, failure reason AVVISAD. eval-4.
tests_ok: true · quality: Backend solid: all /v1/plus/direct-debit routes use preHandler authenticate, every model call is org-scoped (tenant ctx), scheduleCollection validates the linked policy (404 on dangling ref), reconcile is best-effort + idempotent (only SUBMITTED collections ingest). No raw SQL/secrets/eval. Minor non-blocking cosmetic: PaymentProvidersTab reads config.creditorId for display/edit while saved Nordic configs store bankgiroNumber/pbsNumber, so the creditor renders blank and the edit dialog opens empty (resolveCreditorId still round-trips). 'Recurring' in the UI is operator-driven one-at-a-time + manual Run, though an hourly server batch job exists.