On this page
processReaderPayment
mutation · in the family Selling
What it does
Take a card-present payment on the card reader paired to this till.
START one card-present payment on the caller's PAIRED READER: REQUIRES the composite POS session (the x-at-device-session facet — the reader resolves from THE DEVICE, never caller-named: ACTIVE + register-paired, exactly ONE active registered card reader; the device's org chain must equal the order's selling org). The selling org must hold a CONNECTED chargeable account (NO platform arm — the direct-charge money-destination law; CONFLICT/REF_STATE otherwise). Record-first: the Payment mints created with methodRef = the reader's readerRef, THEN the processor intent hands to the reader and this op RETURNS — the customer taps; the payment_intent.amount_capturable_updated truth commits the Tender row + the Order rollup + the created→authorized flip in ONE transaction (the webhook SoT; a fully-delivered order then CAPTURES — the seam), and a reader DECLINE lands the attempt failed via payment_intent.payment_failed. Poll the payment record for the outcome (the CQRS shape). A reader refusal (busy/offline — NO card presented) refuses PAYMENT/READER_UNAVAILABLE with the attempt recorded failed (retryable — record-per-attempt). Requires the unrestricted capability. Template class (the applyTender ring plane — hand-derived v32).
What happens
The order’s remaining amount goes to the physical reader; the customer taps or inserts; the payment confirms back onto the order.
Careful
Real card money. A busy or offline reader refuses retryably — the customer has not paid until the reader confirms.
Who may call it
Capability area: Selling — Ringing sales, serving customers and issuing invoices.
- Owner
- Manager
- Associate Manager
- Sales Associate
- Cashier
- An API key whose scope allows
api:processReaderPayment
Arguments
| Name | Type | Required | Notes |
|---|---|---|---|
input | ProcessReaderPaymentInput ProcessReaderPaymentInput! | yes | No further notes. |
Returns
Payment Payment! — A Payment — a PROCESSOR-backed payment (the integrated processing mode), spawned by a card Tender. Aligned to the deposit→recognition model: authorize = the hold = DEPOSIT at tender; capture = RECOGNIZED at delivery — POS carry-out collapses authorize+capture by ARRIVING at delivery in the same request (the settle instant delivers), never by skipping states. Record-first/processor-after: minted created BEFORE any processor call; the StripePort attempt fires post-commit; state flips ride the ACK/webhook path; 32 attempts bound each order (the Order.paymentIds cap). PCI-min: the PAN never touches AT/stack — the record holds the opaque tokenized methodRef + processor refs + at most brand/last4. The StripePort is FAKED at 7.7a (deterministic, keyless); the live adapter + webhook ingress are 7.7b.
Example request
mutation ExampleProcessReaderPayment($input: ProcessReaderPaymentInput!) {
processReaderPayment(input: $input) {
id
sysId
type
caption
status
parentId
rootId
createdAt
updatedAt
revisionNum
revision
organizationId
amountMinor
tipMinor
currency
methodRef
tenderId
stripeAccountRef
sagaId
intentRef
chargeRef
brand
last4
declineReason
}
}
Variables:
{
"input": {
"orderId": "01900000-0000-7000-8000-f6d8263a0000",
"expectedRevision": "01900000-0000-7000-8000-e02b2e6c0000",
"amountMinor": 1,
"tipMinor": 1
}
}
Send it with the envelope naming the version: "extensions": {"at": {"version": {"name":"genesis","number":0}}}.
Example response
{
"data": {
"processReaderPayment": {
"id": "01900000-0000-7000-8000-37386ae00000",
"sysId": "PY-EXMP-0000-000F",
"type": "Payment",
"caption": "Blue jeans",
"status": "created",
"parentId": "01900000-0000-7000-8000-065235280000",
"rootId": "01900000-0000-7000-8000-a093dd800000",
"createdAt": "2027-01-31T00:00:00.000Z",
"updatedAt": "2027-01-31T00:00:00.000Z",
"revisionNum": 1,
"revision": "01900000-0000-7000-8000-b7960e180000",
"organizationId": "01900000-0000-7000-8000-44b781470000",
"amountMinor": 1,
"tipMinor": 1,
"currency": "USD",
"methodRef": "<method ref>",
"tenderId": "01900000-0000-7000-8000-0ae1978a0000",
"stripeAccountRef": "<stripe account ref>",
"sagaId": "01900000-0000-7000-8000-8b3fa5540000",
"intentRef": "01900000-0000-7000-8000-0cb528b40000",
"chargeRef": "01900000-0000-7000-8000-ae314a160000",
"brand": "<brand>",
"last4": "<last4>",
"declineReason": "<decline reason>"
}
},
"extensions": {
"at": {
"callId": "01EXAMPLE-CALL-ID",
"version": {
"requested": {
"name": "genesis",
"number": 0
},
"serviced": {
"name": "genesis",
"number": 0
}
}
}
}
}
Errors this call can answer
VALIDATION/INVALID— Something in the request is not valid. (VALIDATION)AUTHN/REQUIRED— Sign in to do this. (AUTHN)AUTHZ/FORBIDDEN— Your role does not allow this action. (AUTHZ)RATE_LIMIT/THROTTLED— Too many requests in a short time. (RATE_LIMIT)NOT_FOUND/*— That record could not be found. (NOT_FOUND)CONFLICT/*— The record’s state, or a change made in the meantime, does not allow this; the codes are on the CONFLICT page. (CONFLICT)VALIDATION/VERSION_REQUIRED— The request did not say which app version it came from. (VALIDATION)