@endora-commerce/mod-payments 0.100.0

package/dist/backend/services/payment-service.js

@@ -0,0 +1,134 @@
+import { LockMode } from '@mikro-orm/core';
+import { ERROR_CODES } from '@endora-commerce/contracts';
+import { HttpError } from '@endora-commerce/platform/http';
+import { Payment } from '../entities/payment.entity.js';
+/**
+ * PaymentService (feature 034, FR-024) — opens retry Payments. The first
+ * Payment of an order is created by OrderService.placeOrder; a retry opens a
+ * new row against the same order with the next `attemptNo`, leaving prior
+ * (failed) attempts intact so the admin can see the full history.
+ *
+ * **A fresh attempt row is what makes a gateway able to start over**
+ * (issue #264), which is why the customer-facing retry runs through here rather
+ * than re-driving the failed row. Every gateway keys its own object on this
+ * platform's payment id: PayU sends it as `extOrderId`, which must be unique
+ * per POS; TPay resolves the newest `tpay_transactions` row for the order;
+ * Stripe records a `stripe_payment_intents` mapping per payment. Re-using the
+ * failed attempt asks all four to open a second session against an identifier
+ * they have already spent.
+ */
+export class PaymentService {
+    emFactory;
+    orderRead;
+    constructor(emFactory, orderRead) {
+        this.emFactory = emFactory;
+        this.orderRead = orderRead;
+    }
+    /**
+     * Resolve the order every method below is keyed on, through its owner.
+     *
+     * `Payment` is `@GlobalEntity` — no organization column, no filter — so
+     * `em.find(Payment, { orderId })` answers for every order on the platform.
+     * `Order` is `@OrgScoped`, and `orderReadPort.findById` goes through a
+     * filtered EntityManager, so this read is the whole tenant boundary for an
+     * order-keyed payment operation: an assignment-scoped administrator gets
+     * `null` for an order outside their organizations and the caller stops here.
+     *
+     * It sits in the service rather than in the two admin route handlers on
+     * purpose. A route-level guard protects the routes that exist on the day it
+     * is written; this one protects the next caller too, and both of the routes
+     * that shipped without it were written by someone who had no reason to know
+     * the child carried no filter.
+     *
+     * The buyer's own retry (`PaymentRetryService`) reads and authorises the
+     * order before it gets here, so for that path this is a second read of a row
+     * the identity map already holds — deliberately not optimised away, because
+     * the guarantee must not depend on which caller arrives.
+     *
+     * 404 rather than 403, matching the order-keyed routes in `orders`: an
+     * out-of-scope order must not be distinguishable from one that is not there.
+     */
+    async #assertOrderInScope(orderId) {
+        const order = await this.orderRead.findById(orderId);
+        if (!order) {
+            throw new HttpError(404, ERROR_CODES.ORDER_NOT_FOUND, 'Order not found.');
+        }
+    }
+    /**
+     * The next attempt for `orderId`, opening one only when the latest has
+     * failed.
+     *
+     * The latest attempt is read `FOR UPDATE`, so two callers racing on the same
+     * order serialise here and the second sees what the first wrote: a buyer
+     * double-clicking gets one new attempt, not two. It is the same row the
+     * settlement ingress resolves, so a retry and a late gateway callback cannot
+     * interleave halfway through each other.
+     */
+    async openRetry(orderId) {
+        // command-coverage-ignore: opens a new payment attempt after a failure —
+        // checkout retry mechanics; the order/payment status transition is audited in
+        // the orders flow.
+        await this.#assertOrderInScope(orderId);
+        const em = this.emFactory();
+        return em.transactional(async (tx) => {
+            const latest = await tx.findOne(Payment, { orderId }, { orderBy: { attemptNo: 'desc' }, lockMode: LockMode.PESSIMISTIC_WRITE });
+            if (!latest) {
+                throw new HttpError(404, ERROR_CODES.NOT_FOUND, 'No payment exists for this order to retry.');
+            }
+            if (latest.status === 'paid') {
+                throw new HttpError(409, ERROR_CODES.VALIDATION_FAILED, 'Order is already paid; nothing to retry.');
+            }
+            if (latest.status === 'refunded' || latest.status === 'partially_refunded') {
+                throw new HttpError(409, ERROR_CODES.VALIDATION_FAILED, 'This payment has been refunded; it cannot be retried.');
+            }
+            if (latest.status === 'deferred') {
+                throw new HttpError(409, ERROR_CODES.VALIDATION_FAILED, 'This order is settled out of band; there is nothing to retry.');
+            }
+            // Still open: hand back the attempt that exists rather than opening a
+            // second one beside it. Two live attempts for one order is two provider
+            // objects that can both settle.
+            if (latest.status === 'awaiting_payment') {
+                return { payment: latest, opened: false };
+            }
+            const next = tx.create(Payment, {
+                orderId,
+                paymentMethodId: latest.paymentMethodId,
+                amount: latest.amount,
+                currency: latest.currency,
+                attemptNo: latest.attemptNo + 1,
+            });
+            await tx.persistAndFlush(next);
+            return { payment: next, opened: true };
+        });
+    }
+    /**
+     * Close an attempt whose provider session could not be started.
+     *
+     * The compensating half of {@link openRetry}: the row is written before the
+     * adapter is asked (the adapter needs its id), so an adapter that throws
+     * would otherwise leave an `awaiting_payment` attempt no provider knows
+     * about — and the next retry would *resume* that phantom instead of opening a
+     * real one. Marking it failed puts the order back where the buyer can try
+     * again.
+     */
+    async failAttempt(paymentId, reason) {
+        // command-coverage-ignore: closes an attempt whose provider session never
+        // started, so the buyer's next retry opens a real one — the same retry
+        // mechanics `openRetry` above is exempted for.
+        const em = this.emFactory();
+        await em.transactional(async (tx) => {
+            const payment = await tx.findOne(Payment, { id: paymentId });
+            if (!payment || payment.status !== 'awaiting_payment')
+                return;
+            payment.status = 'failed';
+            payment.failureReason = reason;
+            await tx.flush();
+        });
+    }
+    async listForOrder(orderId) {
+        await this.#assertOrderInScope(orderId);
+        const em = this.emFactory();
+        return em.find(Payment, { orderId }, { orderBy: { attemptNo: 'asc' } });
+    }
+}
+//# sourceMappingURL=payment-service.js.map

package/dist/backend/services/payment-service.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"payment-service.js","sourceRoot":"","sources":["../../../src/backend/services/payment-service.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,QAAQ,EAAE,MAAM,iBAAiB,CAAC;AAE3C,OAAO,EAAE,WAAW,EAAsB,MAAM,4BAA4B,CAAC;AAC7E,OAAO,EAAE,SAAS,EAAE,MAAM,gCAAgC,CAAC;AAC3D,OAAO,EAAE,OAAO,EAAE,MAAM,+BAA+B,CAAC;AAiBxD;;;;;;;;;;;;;;GAcG;AACH,MAAM,OAAO,cAAc;IAEN;IACA;IAFnB,YACmB,SAA8B,EAC9B,SAAwB;QADxB,cAAS,GAAT,SAAS,CAAqB;QAC9B,cAAS,GAAT,SAAS,CAAe;IACxC,CAAC;IAEJ;;;;;;;;;;;;;;;;;;;;;;;OAuBG;IACH,KAAK,CAAC,mBAAmB,CAAC,OAAe;QACvC,MAAM,KAAK,GAAG,MAAM,IAAI,CAAC,SAAS,CAAC,QAAQ,CAAC,OAAO,CAAC,CAAC;QACrD,IAAI,CAAC,KAAK,EAAE,CAAC;YACX,MAAM,IAAI,SAAS,CAAC,GAAG,EAAE,WAAW,CAAC,eAAe,EAAE,kBAAkB,CAAC,CAAC;QAC5E,CAAC;IACH,CAAC;IAED;;;;;;;;;OASG;IACH,KAAK,CAAC,SAAS,CAAC,OAAe;QAC7B,yEAAyE;QACzE,8EAA8E;QAC9E,mBAAmB;QACnB,MAAM,IAAI,CAAC,mBAAmB,CAAC,OAAO,CAAC,CAAC;QACxC,MAAM,EAAE,GAAG,IAAI,CAAC,SAAS,EAAE,CAAC;QAC5B,OAAO,EAAE,CAAC,aAAa,CAAC,KAAK,EAAE,EAAE,EAAE,EAAE;YACnC,MAAM,MAAM,GAAG,MAAM,EAAE,CAAC,OAAO,CAC7B,OAAO,EACP,EAAE,OAAO,EAAE,EACX,EAAE,OAAO,EAAE,EAAE,SAAS,EAAE,MAAM,EAAE,EAAE,QAAQ,EAAE,QAAQ,CAAC,iBAAiB,EAAE,CACzE,CAAC;YACF,IAAI,CAAC,MAAM,EAAE,CAAC;gBACZ,MAAM,IAAI,SAAS,CAAC,GAAG,EAAE,WAAW,CAAC,SAAS,EAAE,4CAA4C,CAAC,CAAC;YAChG,CAAC;YACD,IAAI,MAAM,CAAC,MAAM,KAAK,MAAM,EAAE,CAAC;gBAC7B,MAAM,IAAI,SAAS,CAAC,GAAG,EAAE,WAAW,CAAC,iBAAiB,EAAE,0CAA0C,CAAC,CAAC;YACtG,CAAC;YACD,IAAI,MAAM,CAAC,MAAM,KAAK,UAAU,IAAI,MAAM,CAAC,MAAM,KAAK,oBAAoB,EAAE,CAAC;gBAC3E,MAAM,IAAI,SAAS,CACjB,GAAG,EACH,WAAW,CAAC,iBAAiB,EAC7B,uDAAuD,CACxD,CAAC;YACJ,CAAC;YACD,IAAI,MAAM,CAAC,MAAM,KAAK,UAAU,EAAE,CAAC;gBACjC,MAAM,IAAI,SAAS,CACjB,GAAG,EACH,WAAW,CAAC,iBAAiB,EAC7B,+DAA+D,CAChE,CAAC;YACJ,CAAC;YACD,sEAAsE;YACtE,wEAAwE;YACxE,gCAAgC;YAChC,IAAI,MAAM,CAAC,MAAM,KAAK,kBAAkB,EAAE,CAAC;gBACzC,OAAO,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,KAAK,EAAE,CAAC;YAC5C,CAAC;YACD,MAAM,IAAI,GAAG,EAAE,CAAC,MAAM,CAAC,OAAO,EAAE;gBAC9B,OAAO;gBACP,eAAe,EAAE,MAAM,CAAC,eAAe;gBACvC,MAAM,EAAE,MAAM,CAAC,MAAM;gBACrB,QAAQ,EAAE,MAAM,CAAC,QAAQ;gBACzB,SAAS,EAAE,MAAM,CAAC,SAAS,GAAG,CAAC;aAChC,CAAC,CAAC;YACH,MAAM,EAAE,CAAC,eAAe,CAAC,IAAI,CAAC,CAAC;YAC/B,OAAO,EAAE,OAAO,EAAE,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,CAAC;QACzC,CAAC,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;;;OASG;IACH,KAAK,CAAC,WAAW,CAAC,SAAiB,EAAE,MAAc;QACjD,0EAA0E;QAC1E,uEAAuE;QACvE,+CAA+C;QAC/C,MAAM,EAAE,GAAG,IAAI,CAAC,SAAS,EAAE,CAAC;QAC5B,MAAM,EAAE,CAAC,aAAa,CAAC,KAAK,EAAE,EAAE,EAAE,EAAE;YAClC,MAAM,OAAO,GAAG,MAAM,EAAE,CAAC,OAAO,CAAC,OAAO,EAAE,EAAE,EAAE,EAAE,SAAS,EAAE,CAAC,CAAC;YAC7D,IAAI,CAAC,OAAO,IAAI,OAAO,CAAC,MAAM,KAAK,kBAAkB;gBAAE,OAAO;YAC9D,OAAO,CAAC,MAAM,GAAG,QAAQ,CAAC;YAC1B,OAAO,CAAC,aAAa,GAAG,MAAM,CAAC;YAC/B,MAAM,EAAE,CAAC,KAAK,EAAE,CAAC;QACnB,CAAC,CAAC,CAAC;IACL,CAAC;IAED,KAAK,CAAC,YAAY,CAAC,OAAe;QAChC,MAAM,IAAI,CAAC,mBAAmB,CAAC,OAAO,CAAC,CAAC;QACxC,MAAM,EAAE,GAAG,IAAI,CAAC,SAAS,EAAE,CAAC;QAC5B,OAAO,EAAE,CAAC,IAAI,CAAC,OAAO,EAAE,EAAE,OAAO,EAAE,EAAE,EAAE,OAAO,EAAE,EAAE,SAAS,EAAE,KAAK,EAAE,EAAE,CAAC,CAAC;IAC1E,CAAC;CACF"}

package/dist/backend/services/receive-payment-handler.d.ts

@@ -0,0 +1,260 @@
+import type { EntityManager } from '@mikro-orm/postgresql';
+import { type ReceivePayment } from '@endora-commerce/contracts';
+import type { OrderTransitionPort, PaymentMethodReadPort } from '@endora-commerce/contracts';
+import type { EventBase, EventBus } from '@endora-commerce/platform/events';
+import { Payment } from '../entities/payment.entity.js';
+/**
+ * The one cross-module type this handler names, and the seam feature 075 kept
+ * here **permanently** (D-78 point 2) — now expressed as the owner's own
+ * published interface rather than as its entity class (feature 080, T048;
+ * D-169).
+ *
+ * `payments.order_id` carries a declared foreign key into `orders.id`
+ * (`payments_order_fk`, `on delete restrict`), so this is a genuinely
+ * co-transactional seam: a gateway callback moves the payment row and the
+ * order's `paymentStatus` in one `em.transactional`, and either both land or
+ * neither does. D-78 rules that such a seam keeps the caller's `EntityManager`
+ * and is *declared* — `orders` is in this module's manifest `dependencies` (the
+ * FK already required it), the ledger entry names the constraint, and this
+ * comment says which transaction the write runs in.
+ *
+ * **What T048 changed is who writes the statement, and nothing else.** It used
+ * to be `tx.findOne(Order, …)` here, followed by an assignment onto the managed
+ * entity — this module holding another module's aggregate open on a transaction
+ * it controls, free to move any column of it. It is now
+ * `orderPaymentStatusApplyPort.applyPaymentStatus(tx, …)`: the same transaction,
+ * the same constraint, the same one column, written by the module that owns the
+ * table and answered with a published record. D-168 leaves a packaged `orders`
+ * no entity class for a stranger to name, which is why the conversion had to
+ * happen before `orders` moves; the foreign key needs the **table** and never
+ * the class (D-169), so `payments_order_fk` is untouched.
+ *
+ * **The lifecycle half of that seam is gone since feature 085 Phase D**, and
+ * the ruling is unaffected by its going. `order.status` was written here too,
+ * on the same `tx` — a *transition*, with a graph, guards, an audit entry and
+ * side-effects, none of which a column assignment performs. It moved to
+ * `orderTransitionPort`, called after this transaction has committed. What is
+ * left in the transaction is the money axis, `order.paymentStatus`, which is
+ * the column `payments_order_fk` genuinely holds together with the payment row.
+ *
+ * **It is the only import left, and the other two went because their blocker
+ * did.** They were held open by a sentence that had stopped being true: that
+ * `stripe`, `payu`, `tpay` and `autopay` each construct this handler
+ * themselves, so its constructor could not take a port none of them can build.
+ * All four resolve `receivePaymentPort` today and the one construction left is
+ * in `payments/backend.ts`, where `ctx` is in hand — so the payment-method read
+ * is `paymentMethodReadPort` and the lifecycle write is `orderTransitionPort`.
+ * Neither shares the constraint above: the method read is a read of a row this
+ * transaction never writes (no FK obliges it to be co-transactional, and the
+ * identical read is a port in `shipments`' twin handler), and the transition
+ * runs **after** the commit, for the reason the port's own contract gives.
+ */
+import type { OrderPaymentStatusApplyPort } from '@endora-commerce/mod-orders/ports';
+/**
+ * Re-exported so `backend.ts` names its own module for the same type. One seam,
+ * one ledger entry: a second import specifier in the composition file would be
+ * a second crossing of a boundary that has exactly one reason to be crossed,
+ * and the reason is stated above. `orders` does the same for the two
+ * `EntityManager`-taking interfaces it reads.
+ */
+export type { OrderPaymentStatusApplyPort };
+export interface PaymentEvents extends Record<string, EventBase> {
+    'payment.received.v1': EventBase & {
+        orderId: string;
+        paymentId: string;
+        adapter: string;
+        externalReference: string | null;
+        attemptNo: number;
+    };
+    'payment.failed.v1': EventBase & {
+        orderId: string;
+        paymentId: string;
+        adapter: string;
+        failureReason: string | null;
+        attemptNo: number;
+    };
+    'payment.refunded.v1': EventBase & {
+        orderId: string;
+        paymentId: string;
+        refundedAmount: number;
+        currency: string;
+        fullyRefunded: boolean;
+        externalRefundId: string | null;
+    };
+}
+export type PaymentEventBus = EventBus<PaymentEvents>;
+export interface ReceivePaymentResult {
+    paymentId: string;
+    status: Payment['status'];
+    /**
+     * Where the order stands once the ingress is done with it, which since
+     * feature 085 Phase D is the lifecycle's answer rather than this handler's:
+     * the target the method configured when the graph permitted it, the order's
+     * unchanged status when it did not, and `null` when the ingress asked for no
+     * move at all (a repeated settlement, or a method with no status configured).
+     */
+    orderStatus: string | null;
+    idempotent: boolean;
+}
+/**
+ * The one message this handler logs, as little of a logger as it needs.
+ *
+ * `ctx.log` satisfies it structurally, so `payments/backend.ts` passes the
+ * module's own logger and a test passes a recorder. Declared here rather than
+ * imported so the handler carries no opinion about who is logging — the same
+ * shape `GatewayRefundRegistry` takes for its collision warning.
+ */
+export interface SettlementLogger {
+    warn(details: object, message: string): void;
+}
+/**
+ * ReceivePaymentHandler (feature 034, FR-022/FR-023/FR-025).
+ *
+ * Resolves a Payment from the ingress payload, applies the outcome, and asks
+ * the order lifecycle for the move the method's `statusOnSuccess` /
+ * `statusOnFailure` names. Idempotent: a success after a terminal `paid` is a
+ * no-op; a failure after `paid` is rejected (no downgrade). Resolves a late
+ * event even when the adapter has since been de-registered (it keys on the
+ * persisted Payment, not the live registry).
+ *
+ * **The lifecycle answers; this handler does not decide** (feature 085 Phase
+ * D). It used to assign `order.status` after asking an `OrderStatusRegistry`
+ * whether the code existed, which is a different question from whether the
+ * order may go there — so the ingress wrote transitions the configured graph
+ * forbids, on the happy path, while an operator making the same move by hand
+ * was refused. Existence is now the port's `unknown_status` answer and
+ * reachability its `not_permitted` one, and both leave the order where it is.
+ */
+export declare class ReceivePaymentHandler {
+    private readonly emFactory;
+    /**
+     * The method behind the payment, as `payment_methods` publishes it. Read
+     * inside the settlement transaction, as `shipments` reads its delivery
+     * method: it is a read of a row this transaction never writes, so it is not
+     * held by `payments_order_fk` and carries none of the atomicity the `Order`
+     * import above does. When `payment_methods` is off it throws, inside the
+     * transaction, and the payment and the order roll back together.
+     */
+    private readonly paymentMethodRead;
+    /**
+     * The lifecycle write (feature 085 Phase D). It validates against the
+     * configured graph, runs the veto guards, records the audit entry and
+     * applies the status's side-effects — the five things the assignment this
+     * replaced did none of, which is why a payment-driven cancellation used to
+     * leave the order's stock allocated forever and audited nowhere.
+     *
+     * **Called after this handler's transaction has committed**, never inside
+     * it: the port takes its own `EntityManager`, so a call from inside would
+     * write the order on a different pooled connection whose commit the
+     * enclosing rollback cannot reach (issue #200). The port's own doc block
+     * states the obligation.
+     *
+     * It announces the change too — `OrderTransitionService` emits the
+     * templated `order.status.*.after` events itself — so this handler no
+     * longer resolves `orderStatusAnnouncePort`. Doing both would emit every
+     * payment-driven status change twice.
+     */
+    private readonly orderTransition;
+    /**
+     * The money axis of the order this payment settles (feature 080, T048).
+     *
+     * **Called inside this handler's transaction**, unlike `orderTransition`
+     * above, and the asymmetry is the whole reason there are two ports rather
+     * than one: `payments_order_fk` (`on delete restrict`) holds the payment row
+     * and `orders.payment_status` together, so that write may not commit
+     * separately from this one — while a *lifecycle* transition obtains its own
+     * `EntityManager` and may not run inside it. The interface takes the
+     * caller's `EntityManager` as a required parameter for exactly that reason
+     * (D-169), and the header above states the constraint in full.
+     */
+    private readonly orderPaymentStatus;
+    /** Where a refused transition is recorded; see {@link SettlementLogger}. */
+    private readonly log;
+    private readonly events?;
+    constructor(emFactory: () => EntityManager, 
+    /**
+     * The method behind the payment, as `payment_methods` publishes it. Read
+     * inside the settlement transaction, as `shipments` reads its delivery
+     * method: it is a read of a row this transaction never writes, so it is not
+     * held by `payments_order_fk` and carries none of the atomicity the `Order`
+     * import above does. When `payment_methods` is off it throws, inside the
+     * transaction, and the payment and the order roll back together.
+     */
+    paymentMethodRead: PaymentMethodReadPort, 
+    /**
+     * The lifecycle write (feature 085 Phase D). It validates against the
+     * configured graph, runs the veto guards, records the audit entry and
+     * applies the status's side-effects — the five things the assignment this
+     * replaced did none of, which is why a payment-driven cancellation used to
+     * leave the order's stock allocated forever and audited nowhere.
+     *
+     * **Called after this handler's transaction has committed**, never inside
+     * it: the port takes its own `EntityManager`, so a call from inside would
+     * write the order on a different pooled connection whose commit the
+     * enclosing rollback cannot reach (issue #200). The port's own doc block
+     * states the obligation.
+     *
+     * It announces the change too — `OrderTransitionService` emits the
+     * templated `order.status.*.after` events itself — so this handler no
+     * longer resolves `orderStatusAnnouncePort`. Doing both would emit every
+     * payment-driven status change twice.
+     */
+    orderTransition: OrderTransitionPort, 
+    /**
+     * The money axis of the order this payment settles (feature 080, T048).
+     *
+     * **Called inside this handler's transaction**, unlike `orderTransition`
+     * above, and the asymmetry is the whole reason there are two ports rather
+     * than one: `payments_order_fk` (`on delete restrict`) holds the payment row
+     * and `orders.payment_status` together, so that write may not commit
+     * separately from this one — while a *lifecycle* transition obtains its own
+     * `EntityManager` and may not run inside it. The interface takes the
+     * caller's `EntityManager` as a required parameter for exactly that reason
+     * (D-169), and the header above states the constraint in full.
+     */
+    orderPaymentStatus: OrderPaymentStatusApplyPort, 
+    /** Where a refused transition is recorded; see {@link SettlementLogger}. */
+    log: SettlementLogger, events?: PaymentEventBus | undefined);
+    receive(input: ReceivePayment): Promise<ReceivePaymentResult>;
+    /**
+     * Ask the lifecycle for the move the configured setting names, and answer
+     * where the order ended up.
+     *
+     * Every refusal is a 200 for the provider (contract §"What the caller does
+     * with each outcome"): a PSP retries a non-2xx callback indefinitely, and an
+     * order an operator has already advanced past payment must not be dragged
+     * backwards because a delayed webhook arrived. So the refusal is recorded
+     * here and the settlement stands.
+     *
+     * There is deliberately no `catch`. A `ModuleDisabledError` out of the port's
+     * gate is not a refusal — it is the owner being absent — and swallowing it
+     * would turn fail-closed into fail-open.
+     */
+    private moveOrder;
+    /**
+     * Reflect a gateway refund onto the Payment + Order (feature 049). Driven by
+     * the `charge.refunded` webhook for BOTH Dashboard- and platform-initiated
+     * refunds. `refundedAmount` is the gateway's cumulative total, so this is
+     * idempotent by construction (re-applying the same total is a no-op) and never
+     * calls the gateway back (no refund loop). A fully-refunded payment is never
+     * downgraded to partial.
+     */
+    reflectRefund(input: {
+        paymentId?: string;
+        orderId?: string;
+        /** PaymentIntent id (`pi_…`) — resolves the payment when no paymentId. */
+        externalReference?: string;
+        /** Cumulative refunded amount in major units. */
+        refundedAmount: number;
+        currency: string;
+        fullyRefunded: boolean;
+        externalRefundId?: string | null;
+        providerDetails?: Record<string, unknown>;
+    }): Promise<{
+        paymentId: string;
+        changed: boolean;
+    } | null>;
+    private resolvePaymentForRefund;
+    private resolvePayment;
+}
+//# sourceMappingURL=receive-payment-handler.d.ts.map

package/dist/backend/services/receive-payment-handler.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"receive-payment-handler.d.ts","sourceRoot":"","sources":["../../../src/backend/services/receive-payment-handler.ts"],"names":[],"mappings":"AACA,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,uBAAuB,CAAC;AAC3D,OAAO,EAAqC,KAAK,cAAc,EAAE,MAAM,4BAA4B,CAAC;AACpG,OAAO,KAAK,EAEV,mBAAmB,EACnB,qBAAqB,EACtB,MAAM,4BAA4B,CAAC;AACpC,OAAO,KAAK,EAAE,SAAS,EAAE,QAAQ,EAAE,MAAM,kCAAkC,CAAC;AAE5E,OAAO,EAAE,OAAO,EAAE,MAAM,+BAA+B,CAAC;AACxD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6CG;AACH,OAAO,KAAK,EAAE,2BAA2B,EAAE,MAAM,mCAAmC,CAAC;AACrF;;;;;;GAMG;AACH,YAAY,EAAE,2BAA2B,EAAE,CAAC;AAE5C,MAAM,WAAW,aAAc,SAAQ,MAAM,CAAC,MAAM,EAAE,SAAS,CAAC;IAC9D,qBAAqB,EAAE,SAAS,GAAG;QACjC,OAAO,EAAE,MAAM,CAAC;QAChB,SAAS,EAAE,MAAM,CAAC;QAClB,OAAO,EAAE,MAAM,CAAC;QAChB,iBAAiB,EAAE,MAAM,GAAG,IAAI,CAAC;QACjC,SAAS,EAAE,MAAM,CAAC;KACnB,CAAC;IACF,mBAAmB,EAAE,SAAS,GAAG;QAC/B,OAAO,EAAE,MAAM,CAAC;QAChB,SAAS,EAAE,MAAM,CAAC;QAClB,OAAO,EAAE,MAAM,CAAC;QAChB,aAAa,EAAE,MAAM,GAAG,IAAI,CAAC;QAC7B,SAAS,EAAE,MAAM,CAAC;KACnB,CAAC;IACF,qBAAqB,EAAE,SAAS,GAAG;QACjC,OAAO,EAAE,MAAM,CAAC;QAChB,SAAS,EAAE,MAAM,CAAC;QAClB,cAAc,EAAE,MAAM,CAAC;QACvB,QAAQ,EAAE,MAAM,CAAC;QACjB,aAAa,EAAE,OAAO,CAAC;QACvB,gBAAgB,EAAE,MAAM,GAAG,IAAI,CAAC;KACjC,CAAC;CACH;AACD,MAAM,MAAM,eAAe,GAAG,QAAQ,CAAC,aAAa,CAAC,CAAC;AAEtD,MAAM,WAAW,oBAAoB;IACnC,SAAS,EAAE,MAAM,CAAC;IAClB,MAAM,EAAE,OAAO,CAAC,QAAQ,CAAC,CAAC;IAC1B;;;;;;OAMG;IACH,WAAW,EAAE,MAAM,GAAG,IAAI,CAAC;IAC3B,UAAU,EAAE,OAAO,CAAC;CACrB;AAED;;;;;;;GAOG;AACH,MAAM,WAAW,gBAAgB;IAC/B,IAAI,CAAC,OAAO,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,GAAG,IAAI,CAAC;CAC9C;AAUD;;;;;;;;;;;;;;;;;GAiBG;AACH,qBAAa,qBAAqB;IAE9B,OAAO,CAAC,QAAQ,CAAC,SAAS;IAC1B;;;;;;;OAOG;IACH,OAAO,CAAC,QAAQ,CAAC,iBAAiB;IAClC;;;;;;;;;;;;;;;;;OAiBG;IACH,OAAO,CAAC,QAAQ,CAAC,eAAe;IAChC;;;;;;;;;;;OAWG;IACH,OAAO,CAAC,QAAQ,CAAC,kBAAkB;IACnC,4EAA4E;IAC5E,OAAO,CAAC,QAAQ,CAAC,GAAG;IACpB,OAAO,CAAC,QAAQ,CAAC,MAAM,CAAC;gBA5CP,SAAS,EAAE,MAAM,aAAa;IAC/C;;;;;;;OAOG;IACc,iBAAiB,EAAE,qBAAqB;IACzD;;;;;;;;;;;;;;;;;OAiBG;IACc,eAAe,EAAE,mBAAmB;IACrD;;;;;;;;;;;OAWG;IACc,kBAAkB,EAAE,2BAA2B;IAChE,4EAA4E;IAC3D,GAAG,EAAE,gBAAgB,EACrB,MAAM,CAAC,EAAE,eAAe,YAAA;IAGrC,OAAO,CAAC,KAAK,EAAE,cAAc,GAAG,OAAO,CAAC,oBAAoB,CAAC;IAgJnE;;;;;;;;;;;;;OAaG;YACW,SAAS;IAiCvB;;;;;;;OAOG;IACG,aAAa,CAAC,KAAK,EAAE;QAGzB,SAAS,CAAC,EAAE,MAAM,CAAC;QACnB,OAAO,CAAC,EAAE,MAAM,CAAC;QACjB,0EAA0E;QAC1E,iBAAiB,CAAC,EAAE,MAAM,CAAC;QAC3B,iDAAiD;QACjD,cAAc,EAAE,MAAM,CAAC;QACvB,QAAQ,EAAE,MAAM,CAAC;QACjB,aAAa,EAAE,OAAO,CAAC;QACvB,gBAAgB,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;QACjC,eAAe,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC;KAC3C,GAAG,OAAO,CAAC;QAAE,SAAS,EAAE,MAAM,CAAC;QAAC,OAAO,EAAE,OAAO,CAAA;KAAE,GAAG,IAAI,CAAC;YAkF7C,uBAAuB;YAoBvB,cAAc;CAkB7B"}