---
phase: 56-order-payments
plan: 01
status: complete
completed: 2026-03-30
---

## Summary

Uruchomienie funkcji dodawania platnosci do zamowienia z zakladki Platnosci + push statusu platnosci do shopPRO API.

## What Was Built

- Migracja `20260330_000073_create_order_payments_table.sql` — tabela `order_payments` (INT UNSIGNED FK) + idempotentne kolumny `total_with_tax`, `total_paid`, `external_payment_type_id` w `orders`
- `OrdersRepository::addPayment()` — INSERT + przeliczenie total_paid i payment_status
- `OrdersRepository::findOrderSourceInfo()` — dane source/integration dla push
- `OrdersController::addPayment()` — POST `/orders/{id}/payment/add` z walidacja, try/catch, activity log
- `OrdersController::pushPaymentToShoppro()` — push `set_paid` do shopPRO API po pelnym oplaceniu
- `ShopproApiClient::setOrderPaid()` — PUT `/api.php?endpoint=orders&action=set_paid`
- Formularz inline w zakladce Platnosci (przycisk "Dodaj platnosc", pola: kwota/typ/data/komentarz, AJAX submit)
- Style `.payment-add-form` w SCSS

## Deviations

- FK type fix: `order_payments.order_id` zmieniony z BIGINT na INT UNSIGNED (zgodnosc z `orders.id`)
- `Csrf::verify()` → `Csrf::validate()` (poprawna nazwa metody)
- Dodano try/catch w kontrolerze dla lepszej diagnostyki bledow

## Decisions

| Decision | Rationale |
|----------|-----------|
| Push set_paid do shopPRO bez nowego endpointu | shopPRO API juz ma `set_paid` — wystarczajace |
| ShopproIntegrationsRepository jako nullable dep w OrdersController | Minimalna zmiana konstruktora |