The Payments API handles the full receipt-based payment flow used by Krafta. Customers submit a bank transfer or Pago Móvil receipt tied to an existing order; admins then confirm or reject each submission. ActiveDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/PloutusLab/krafta-web/llms.txt
Use this file to discover all available pages before exploring further.
PaymentAccount records are exposed to the checkout UI so customers always see up-to-date bank details.
POST /api/payments
Submit a payment receipt for an existing order. The endpoint creates aPaymentSubmission record, sets the order’s status to REPORTED, and returns the new submission’s ID. No authentication is required — any client may submit a receipt as long as they hold a valid orderId.
Request body
The UUID of the order being paid. Must match an existing
Order record.Payment method used. Accepted values:
"PAGO_MOVIL" or "TRANSFERENCIA".The amount the customer reports having sent, in bolívares (Bs.). Stored as
amountReported on the PaymentSubmission; the order’s total is used separately as amountExpected.The bank reference or transaction confirmation number issued by the sending institution.
Name of the customer’s sending bank (e.g.,
"Banesco", "Mercantil").Full legal name of the account holder who made the transfer.
URL of the uploaded receipt image. Use the Upload API to obtain this value before calling this endpoint.
Response
Always
true on a successful submission.UUID of the newly created
PaymentSubmission. Store this value if you need to reference the submission in admin verification calls.Side effects
- The matching
Orderrecord’sstatusis updated toREPORTED. - A new
PaymentSubmissionrow is created withstatus: "REPORTED"andreportedAtset to the current timestamp.
Error responses
| Status | Condition |
|---|---|
400 | orderId or reference missing from the request body. |
500 | Unexpected server error. |
PUT /api/payments ADMIN
Verify or reject a previously submitted payment receipt. Requires theADMIN role. When confirmed, the order moves to CONFIRMED and the payment record is marked verified. When rejected, both records are set to REJECTED and an optional reason is stored for display to the customer.
Request body
The UUID of the order whose payment status is being updated.
UUID of the specific
PaymentSubmission to update. If omitted, all submissions on the order are updated.Verification outcome. Accepted values:
"CONFIRMED" or "REJECTED".Human-readable explanation shown to the customer when
status is "REJECTED". Stored on the PaymentSubmission.rejectionReason field.Response
Side effects
status value | Order.status | PaymentSubmission.status |
|---|---|---|
"CONFIRMED" | CONFIRMED | CONFIRMED + verifiedAt timestamp set |
"REJECTED" | REJECTED | REJECTED + rejectionReason stored |
Error responses
| Status | Condition |
|---|---|
400 | orderId or status missing. |
401 / 403 | Caller does not hold the ADMIN role. |
500 | Unexpected server error. |
GET /api/payments/accounts
Returns all activePaymentAccount records. This endpoint is unauthenticated and is called during checkout to display the bank details customers must transfer funds to. If the database is unreachable, a built-in seed fallback (Banesco + Binance) is returned so checkout never breaks.
Response
Always
true on success.Array of active
PaymentAccount objects. Only records with active: true are returned.