Problem
- Checkout potrzebuje jednego kontraktu płatności zamiast zależności od szczegółów konkretnej bramki.
- Ryzyka projektu to ponowione obciążenia, niespójne statusy płatności, niezweryfikowane callbacki i brak czytelnego audytu prób.
Case study backend PHP
Payment Adapter
Kontekst: moduł płatności z jednym kontraktem dla różnych bramek. Problemem są duplikaty eventów, niespójne statusy i trudne odtworzenie przebiegu charge, refund oraz webhook replay.
Case study
Zakres techniczny
Część repozytoriów jest prywatna do czasu zamknięcia prac. Zakres projektu, decyzje techniczne i scenariusze działania są opisane na stronie. Kod mogę omówić na rozmowie technicznej.
Decyzja techniczna
- Wspólny port bramki, Money VO, znormalizowany wynik płatności, HMAC webhook, idempotencja skutku i audit log prób płatniczych.
- PaymentGatewayInterface oddziela logikę aplikacji od konkretnego dostawcy płatności.
- PaymentService centralizuje charge, refund, obsługę webhooków, idempotencję i historię prób.
Efekt
- Projekt pokazuje, jak ograniczać ryzyko podwójnego przetworzenia płatności i jak zostawić ścieżkę diagnostyczną dla spornych przypadków.
- Wspólny kontrakt bramki oraz adaptery Stripe i PayPal.
- Scenariusze charge, refund, replay idempotencyjny i weryfikacja webhooka.
- Przykład mapowania zamówienia ShopFlow na request płatniczy oraz audyt prób i webhooków.
Stack
- PHP / Adapter / Webhook / Audit
- composer install
- composer demo-all
- composer webhook-demo