> ## Documentation Index > Fetch the complete documentation index at: https://docs-pos.solya.app/llms.txt > Use this file to discover all available pages before exploring further. # Refund an acompte / caution as store credit (avoir) > Refunds a subject the customer paid into — an acompte on a special order, a caution — by minting a REDEEMABLE avoir (`store_credit` instrument) for the amount, and records the refund. The avoir and the refund record are written in ONE transaction, so a refund can never exist without the spendable instrument it promises. The response carries the `instrumentCode` to hand to the customer. This is NOT a return: a refunded acompte has no article, no reason code and no stock impact, so it is deliberately absent from the return statistics — use `POST /returns` to send goods back. The CALLER supplies the refund `id`; it is the idempotency anchor, so replaying a request returns the SAME refund and mints nothing further. Money is integer cents. The amount is REFUSED (422), never trimmed, when it exceeds what is still refundable — read `GET /refunds/refundable/{subjectKind}/{subjectId}` first to know the bound. MANAGER ELEVATION. Minting the avoir asserts `giftcard:issue`, which `pos.returns.manage` does not imply: a cashier must present a manager's single-use `x-elevation-token` (obtained from `POST /elevation` for the `refund.storeCredit` operation, whose approver holds `pos.giftcard.manage`) or the call is refused 403. Every other refusal is evaluated BEFORE the token is consumed, so a rejected request never costs a manager their PIN. MODALITY. Whether refunds go back as store credit or to the original payment method is a platform setting (`refund.modality` in `PUT /settings`). This route serves the `store_credit` modality; when the merchant has configured `original_method` it refuses 422 rather than silently handing out an avoir. Failure conditions: 400 on a malformed body; 403 without `sale:refund` or without the elevation the mint requires; 404 when the subject is unknown; 422 when the amount exceeds the refundable balance or the configured modality is not store credit. ## OpenAPI ````yaml /openapi.json post /v1/refunds/store-credit openapi: 3.0.3 info: title: Solya POS API version: 1.0.0 description: >- The Solya POS backend HTTP surface. Every documented operation is agent-ready: it carries an `operationId`, an agent-facing `description`, the `pos.*` scopes it enforces (`x-required-permissions`) and an `x-agent-tier`. Success responses return the payload as raw JSON; failures return the `ErrorResponse` envelope (`{ error: { code, message, statusCode } }`). servers: - url: / description: The backend, relative to its deployed origin. security: [] paths: /v1/refunds/store-credit: post: tags: - Returns summary: Refund an acompte / caution as store credit (avoir) description: >- Refunds a subject the customer paid into — an acompte on a special order, a caution — by minting a REDEEMABLE avoir (`store_credit` instrument) for the amount, and records the refund. The avoir and the refund record are written in ONE transaction, so a refund can never exist without the spendable instrument it promises. The response carries the `instrumentCode` to hand to the customer. This is NOT a return: a refunded acompte has no article, no reason code and no stock impact, so it is deliberately absent from the return statistics — use `POST /returns` to send goods back. The CALLER supplies the refund `id`; it is the idempotency anchor, so replaying a request returns the SAME refund and mints nothing further. Money is integer cents. The amount is REFUSED (422), never trimmed, when it exceeds what is still refundable — read `GET /refunds/refundable/{subjectKind}/{subjectId}` first to know the bound. MANAGER ELEVATION. Minting the avoir asserts `giftcard:issue`, which `pos.returns.manage` does not imply: a cashier must present a manager's single-use `x-elevation-token` (obtained from `POST /elevation` for the `refund.storeCredit` operation, whose approver holds `pos.giftcard.manage`) or the call is refused 403. Every other refusal is evaluated BEFORE the token is consumed, so a rejected request never costs a manager their PIN. MODALITY. Whether refunds go back as store credit or to the original payment method is a platform setting (`refund.modality` in `PUT /settings`). This route serves the `store_credit` modality; when the merchant has configured `original_method` it refuses 422 rather than silently handing out an avoir. Failure conditions: 400 on a malformed body; 403 without `sale:refund` or without the elevation the mint requires; 404 when the subject is unknown; 422 when the amount exceeds the refundable balance or the configured modality is not store credit. operationId: issueStoreCreditRefund requestBody: required: true content: application/json: schema: type: object properties: id: type: string minLength: 1 subjectKind: type: string enum: - deposit subjectId: type: string minLength: 1 amountCents: type: integer minimum: 0 exclusiveMinimum: true maximum: 9007199254740991 note: type: string maxLength: 500 required: - id - subjectKind - subjectId - amountCents example: id: ref-2026-000128 subjectKind: deposit subjectId: dep-4417 amountCents: 4500 note: Réparation impossible — acompte rendu responses: '201': description: >- The recorded refund, including the minted avoir's id and bearer code. content: application/json: schema: type: object properties: id: type: string subjectKind: type: string enum: - deposit subjectId: type: string customerId: type: string storeId: type: string currency: type: string amountCents: type: integer minimum: 0 exclusiveMinimum: true maximum: 9007199254740991 modality: type: string enum: - store_credit - original_method instrumentId: type: string instrumentCode: type: string note: nullable: true type: string actorId: type: string refundedAt: type: string required: - id - subjectKind - subjectId - customerId - storeId - currency - amountCents - modality - instrumentId - instrumentCode - note - actorId - refundedAt additionalProperties: false description: >- The recorded refund, including the minted avoir's id and bearer code. example: id: ref-2026-000128 subjectKind: deposit subjectId: dep-4417 customerId: cus-882 storeId: store-paris-01 currency: EUR amountCents: 4500 modality: store_credit instrumentId: avoir-ref-2026-000128 instrumentCode: AV-K7QMD3PZRT note: Réparation impossible — acompte rendu actorId: usr-cashier-12 refundedAt: '2026-08-05T09:41:07.000Z' '400': description: >- The request failed schema validation; `error.fieldErrors` lists the fields. content: application/json: schema: $ref: '#/components/schemas/ValidationErrorResponse' '401': description: No valid credential was presented — send a bearer token. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '403': description: The actor is authenticated but lacks the required `pos.*` scope. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '404': description: No resource matches the addressed identifier. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '422': description: The request is well-formed but violates a domain rule. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '500': description: An unexpected server error — safe to retry idempotent requests. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' security: - bearerAuth: [] components: schemas: ValidationErrorResponse: type: object required: - error additionalProperties: false description: >- A `VALIDATION_FAILED` envelope carrying the offending fields in `fieldErrors`. properties: error: type: object required: - code - message - statusCode additionalProperties: false properties: code: type: string enum: - VALIDATION_FAILED message: type: string statusCode: type: integer fieldErrors: type: array description: >- One entry per rejected field: the field path and why it was rejected. items: type: object required: - field - message additionalProperties: false properties: field: type: string description: Dot-path of the offending field. message: type: string description: Why the field was rejected. ErrorResponse: type: object required: - error additionalProperties: false description: The uniform failure envelope every non-2xx response returns. properties: error: type: object required: - code - message - statusCode additionalProperties: false properties: code: type: string enum: - VALIDATION_FAILED - UNAUTHORIZED - FORBIDDEN - NOT_FOUND - CONFLICT - BUSINESS_RULE_VIOLATION - INTERNAL_ERROR description: >- Machine-readable kernel `ResultCode` — branch on this, not on `message`. message: type: string description: >- Human-readable explanation. Safe to surface; never leaks server internals. statusCode: type: integer description: >- The HTTP status, mirrored into the body so a client need not read headers. securitySchemes: bearerAuth: type: http scheme: bearer bearerFormat: JWT description: >- `Authorization: Bearer `. Accepts EITHER a Keycloak access token (scopes-in-token) OR an opaque POS session token; both resolve to the same `pos.*` scope vocabulary the route guards enforce. ````