Purpose
Explain how PayPress submits refunds and keeps local status synchronized.
Overview
PayPress supports admin-triggered full refunds from Order Details. Stripe executes the refund, and Stripe webhooks remain authoritative for final local status.
How It Works
When an admin confirms a refund, PayPress resolves the refundable Stripe object using stored payment intent, charge, or invoice information. It reserves a stable refund operation UUID and sends the refund request with an installation-scoped idempotency key.
Important Components
- Refund setting.
- Order Details Danger Zone.
- Payment intent/charge/invoice resolution.
- Refund operation UUID.
- Installation UUID.
- Stable idempotency key.
- Refund webhooks.
- Refund diagnostics.
Data Flow
Admin requests refund -> eligibility check -> operation UUID reserved -> Stripe refund request -> immediate admin notice -> refund webhooks update local order status and totals.
Security Considerations
Refund actions require admin capability and nonce checks. Idempotency keys include installation identity to avoid collisions across multiple sites using the same Stripe account.
Known Limitations
Merchant-entered partial refunds are not implemented. A future partial-refund release may require operation-level history or a dedicated refund operations table.