# Phase 14.3 — Payment Requests

| Field | Value |
| --- | --- |
| Identifier | `payment-14.3` |
| Implementation Priority | **HIGH** |
| Status | Complete |
| Service | `payment` |
| Depends On | `payment-14.2` |

> Full specification: [payment-roadmap.md](../../payment-roadmap.md#phase-14-3--payment-requests)

## Purpose

Idempotent payment request initiation for any vertical — amount, currency (IRR first), commercial refs, redirect/token payload from selected PSP.

## Business Scope

Initiate pay for order/invoice/membership/checkout refs. Expire abandoned requests. Route via BYO-PSP or facilitator merchant.

## Technical Scope

Aggregates: PaymentRequest, PaymentRequestLine, PaymentRequestStatusHistory. Idempotency-Key enforcement. Adapter `initiate_payment()`.

## Dependencies

`payment-14.2`, active PSP connection or merchant account

## Out of Scope

Callbacks (14.4), ledger (14.5), refunds (14.6).

## Capabilities

`payment.requests`, `payment.initiate`, `payment.idempotency`

## Permissions

`payment.requests.view|create|cancel|manage`; internal `payment.requests.create`

## Events

`payment.request.created|redirect_issued|expired|cancelled|failed`

## API Contracts

POST/GET `/api/v1/payment-requests`, POST `.../cancel`, internal `/internal/v1/payment-requests`

## Data Ownership

Payment owns request lifecycle; vertical owns commercial aggregate.

## Provider Ownership

PSP initiate APIs in adapters only.

## Integration Rules

Verticals pass refs only. Duplicate idempotency key returns same request.

## Quality Gates

Idempotency, amount validation, state machine, tenant isolation.

## Definition of Done

Mock initiate returns redirect payload; events emitted; ledger deferred to 14.5.

## Future Compatibility

Multi-currency; tokenized card metadata slots.