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.
91 lines
2.7 KiB
Go
91 lines
2.7 KiB
Go
package yookassa
|
|
|
|
import (
|
|
"testing"
|
|
)
|
|
|
|
func TestParseNotification(t *testing.T) {
|
|
n, err := ParseNotification([]byte(`{"type":"notification","event":"payment.succeeded",
|
|
"object":{"id":"pay-1","status":"succeeded","paid":true,"metadata":{"order_id":"0197-order"}}}`))
|
|
if err != nil {
|
|
t.Fatalf("parse notification: %v", err)
|
|
}
|
|
if n.Event != EventPaymentSucceeded {
|
|
t.Errorf("event = %q, want %q", n.Event, EventPaymentSucceeded)
|
|
}
|
|
p, err := n.Payment()
|
|
if err != nil {
|
|
t.Fatalf("decode notification payment: %v", err)
|
|
}
|
|
if p.ID != "pay-1" {
|
|
t.Errorf("payment id = %q, want pay-1", p.ID)
|
|
}
|
|
if p.OrderID() != "0197-order" {
|
|
t.Errorf("order id = %q, want the order carried in metadata", p.OrderID())
|
|
}
|
|
}
|
|
|
|
func TestParseNotificationRejectsNonEnvelopes(t *testing.T) {
|
|
for name, body := range map[string]string{
|
|
"not json": `nonsense`,
|
|
"wrong type": `{"type":"payment","event":"payment.succeeded","object":{"id":"pay-1"}}`,
|
|
"no event": `{"type":"notification","object":{"id":"pay-1"}}`,
|
|
"empty object": `{}`,
|
|
} {
|
|
if _, err := ParseNotification([]byte(body)); err == nil {
|
|
t.Errorf("%s: accepted as a notification envelope", name)
|
|
}
|
|
}
|
|
}
|
|
|
|
func TestNotificationPaymentNeedsAnID(t *testing.T) {
|
|
// Without an id there is nothing to re-read from the API, and the body itself is never evidence.
|
|
n, err := ParseNotification([]byte(`{"type":"notification","event":"payment.succeeded","object":{"status":"succeeded"}}`))
|
|
if err != nil {
|
|
t.Fatalf("parse notification: %v", err)
|
|
}
|
|
if _, err := n.Payment(); err == nil {
|
|
t.Error("a payment object with no id was accepted")
|
|
}
|
|
}
|
|
|
|
func TestAllowedSender(t *testing.T) {
|
|
allowed := []string{
|
|
"185.71.76.0", "185.71.76.31", // /27 bounds
|
|
"185.71.77.15",
|
|
"77.75.153.0", "77.75.153.127", // /25 bounds
|
|
"77.75.156.11", "77.75.156.35", // the two single addresses
|
|
"77.75.154.128", "77.75.154.255",
|
|
"2a02:5180::1", "2a02:5180:ffff::abcd",
|
|
}
|
|
for _, ip := range allowed {
|
|
if !AllowedSender(ip) {
|
|
t.Errorf("%s rejected, want allowed", ip)
|
|
}
|
|
}
|
|
denied := []string{
|
|
"185.71.76.32", "185.71.75.255", // just outside the /27
|
|
"77.75.153.128", // just outside the /25
|
|
"77.75.156.12", // adjacent to a single allowed address
|
|
"77.75.154.127",
|
|
"2a02:5181::1",
|
|
"8.8.8.8", "127.0.0.1", "",
|
|
"not an address",
|
|
}
|
|
for _, ip := range denied {
|
|
if AllowedSender(ip) {
|
|
t.Errorf("%s allowed, want rejected", ip)
|
|
}
|
|
}
|
|
}
|
|
|
|
func TestAllowedSenderUnmapsIPv4(t *testing.T) {
|
|
// A dual-stack listener reports an IPv4 peer as ::ffff:a.b.c.d; it must still match the v4 range.
|
|
if !AllowedSender("::ffff:77.75.156.11") {
|
|
t.Error("an IPv4-mapped allowed sender was rejected")
|
|
}
|
|
if AllowedSender("::ffff:8.8.8.8") {
|
|
t.Error("an IPv4-mapped foreign sender was allowed")
|
|
}
|
|
}
|