Ilia Denisov
92ba527575
CI / changes (pull_request) Successful in 2s
CI / unit (pull_request) Successful in 11s
CI / integration (pull_request) Successful in 25s
CI / ui (pull_request) Successful in 1m17s
CI / conformance (pull_request) Successful in 10s
CI / gate (pull_request) Successful in 0s
CI / deploy (pull_request) Successful in 1m50s
Replace Robokassa with YooKassa as the RUB direct-rail provider. The wallet
model is untouched: one `direct` segment, the same spend wall, the same
per-channel merchant shops (D42) and `shop` on the order (D44).
The two providers are not shaped alike, and that drives the change:
- Opening a purchase is now an outbound API call (`POST /v3/payments`,
single-stage capture, redirect confirmation). The order id is both the
`Idempotence-Key` and `metadata.order_id`, so a retried create cannot mint a
second payment and a notification always resolves to its order.
- YooKassa does NOT sign notifications, so the body is never evidence: it only
names a payment, which is re-read with `GET /v3/payments/{id}`, and only that
answer is acted on. Two guards ride on it — the payment's metadata must name
the order, and its `test` flag must match the shop's, so a test-shop payment
can never credit real chips. The sender address is checked against YooKassa's
published ranges first, which stops a forger turning each fabricated
notification into an outbound call of ours.
- A notification lost for good would leave the money taken and the chips unowed,
silently. The existing pending-order reaper now asks the provider about each
order that reached its expiry age carrying a payment id, and credits the ones
really paid — one request per order over its whole life, not polling.
- `payment.canceled` records a `failed` event, so a declined payment is finally
surfaced to the customer as PAYMENTS.md §9 already specified.
- The admin refund moves the money through `POST /v3/refunds` before recording
anything; a failed call records nothing, so the ledger cannot claim a refund
that did not happen, and the recorded id is the provider's own.
- YooKassa has no cabinet-side generic receipt: «Чеки от ЮKassa» registers one
only if the request carries it, so every payment and refund now sends an
itemized `receipt` to the D36 confirmed email. The VAT rate code is a deploy
variable; the settlement subject and method are constants.
Robokassa is retired, not deleted: the direct rail falls back to it when no
YooKassa shop is configured and no deployment sets its credentials, so reviving
it is a credentials change rather than a code change. Its variables are removed
from compose, .env.example, write-prod-env.sh and the three workflows, and
recorded in backend/internal/robokassa/README.md together with the cabinet
configuration and the revival steps. Ledger rows keep `provider = 'robokassa'`;
that literal is load-bearing for the idempotency index.
No migration and no wire change: `orders.provider_payment_id` already existed,
and the client is rail-agnostic.
Decisions D47-D51 (revising D41) and stage E12 are baked into the docs.
55 lines
2.5 KiB
Go
55 lines
2.5 KiB
Go
package payments
|
|
|
|
import (
|
|
"context"
|
|
|
|
"github.com/google/uuid"
|
|
)
|
|
|
|
// providerAdmin tags an operator-initiated refund in the ledger, distinct from a rail's own refund
|
|
// (robokassa / vk / telegram). The refund idempotency key (providerAdmin, order id) allows exactly
|
|
// one manual full refund per order.
|
|
const providerAdmin = "admin"
|
|
|
|
// RefundOrderFull refunds a paid order in full at the operator's request, recording the reversal
|
|
// only. It is for the rails that have no refund API of our own to call: the operator performs the
|
|
// actual money refund there by hand (VK support, Telegram refundStarPayment, the Robokassa cabinet),
|
|
// and this records it under the operator's own idempotency key.
|
|
func (s *Service) RefundOrderFull(ctx context.Context, orderID uuid.UUID) (RefundOutcome, error) {
|
|
return s.RefundOrderFullAs(ctx, orderID, providerAdmin, orderID.String())
|
|
}
|
|
|
|
// RefundOrderFullAs refunds a paid order in full and records it under the given provider and refund
|
|
// id: it revokes the funded chips best-effort (floored at 0, never negative — D27), appends a refund
|
|
// ledger row and is idempotent on (provider, providerRefundID), so a second call reports
|
|
// AlreadyRefunded. Callers whose rail moved the money through an API pass that rail's own refund id,
|
|
// which keeps the ledger reconcilable against the provider's records; the refund id is distinct from
|
|
// the fund's payment id, so the two rows coexist under the same partial-unique index.
|
|
//
|
|
// The provider-side money movement must already have succeeded when this is called — the ledger must
|
|
// never claim a refund that did not happen.
|
|
func (s *Service) RefundOrderFullAs(ctx context.Context, orderID uuid.UUID, provider, providerRefundID string) (RefundOutcome, error) {
|
|
o, err := s.store.orderByID(ctx, orderID)
|
|
if err != nil {
|
|
return RefundOutcome{}, err
|
|
}
|
|
refunded, err := MoneyFromMinor(o.expectedAmount, Currency(o.currency))
|
|
if err != nil {
|
|
return RefundOutcome{}, err
|
|
}
|
|
return s.store.refund(ctx, orderID, provider, providerRefundID, refunded, s.clock())
|
|
}
|
|
|
|
// LedgerExportRow is one append-only ledger row for the tax / reconciliation export, carrying the
|
|
// account it belongs to alongside the entry fields.
|
|
type LedgerExportRow struct {
|
|
AccountID string
|
|
LedgerEntry
|
|
}
|
|
|
|
// LedgerExport reads the entire append-only ledger (all accounts, newest first) for a CSV/JSON
|
|
// export — tax reporting and future rail reconciliation. Uncached, admin-only.
|
|
func (s *Service) LedgerExport(ctx context.Context) ([]LedgerExportRow, error) {
|
|
return s.store.allLedger(ctx)
|
|
}
|