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.
59 lines
2.2 KiB
Go
59 lines
2.2 KiB
Go
package yookassa
|
|
|
|
// Shops is a set of YooKassa merchant shops keyed by channel — the subtype of the trusted X-Platform
|
|
// signal for the direct rail ("web", "android"; "ios" later). The direct rail routes a payment to the
|
|
// per-channel shop for separate merchant accounts, accounting and receipts, while every shop still
|
|
// credits the one direct wallet (docs/PAYMENTS_DECISIONS_ru.md D42). An empty set leaves the direct
|
|
// order and notification endpoints unregistered.
|
|
type Shops map[string]Config
|
|
|
|
// Channel constants name the direct-rail X-Platform subtypes a shop is keyed by. ChannelWeb is the
|
|
// default: an unknown or empty channel routes here on the order side.
|
|
const (
|
|
ChannelWeb = "web"
|
|
ChannelAndroid = "android"
|
|
)
|
|
|
|
// Shop returns the shop that issues an order for channel, falling back to the web shop when channel
|
|
// is unknown, empty or not configured. The fallback is safe: routing only chooses the merchant
|
|
// account and receipt, never the credited wallet (always direct, D42), so a mis-attributed channel
|
|
// costs at most accounting accuracy, not money. The second result is false when neither the channel
|
|
// nor the web shop is configured.
|
|
func (s Shops) Shop(channel string) (Config, bool) {
|
|
if channel != "" {
|
|
if c, ok := s[channel]; ok && c.Configured() {
|
|
return c, true
|
|
}
|
|
}
|
|
if c, ok := s[ChannelWeb]; ok && c.Configured() {
|
|
return c, true
|
|
}
|
|
return Config{}, false
|
|
}
|
|
|
|
// ByShopID returns the shop with the given YooKassa shop id, which is how an incoming notification is
|
|
// attributed to one of several configured shops (the payment object reports it as
|
|
// recipient.account_id). Unlike Shop it does not fall back: an unrecognised shop id means the
|
|
// notification was not meant for us, and the caller must not guess at credentials.
|
|
func (s Shops) ByShopID(shopID string) (channel string, cfg Config, ok bool) {
|
|
if shopID == "" {
|
|
return "", Config{}, false
|
|
}
|
|
for ch, c := range s {
|
|
if c.Configured() && c.ShopID == shopID {
|
|
return ch, c, true
|
|
}
|
|
}
|
|
return "", Config{}, false
|
|
}
|
|
|
|
// Configured reports whether at least one shop has credentials (the YooKassa direct rail is live).
|
|
func (s Shops) Configured() bool {
|
|
for _, c := range s {
|
|
if c.Configured() {
|
|
return true
|
|
}
|
|
}
|
|
return false
|
|
}
|