Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Edfermachado/proyectoSistemas/llms.txt

Use this file to discover all available pages before exploring further.

UniEvents uses a two-step manual payment flow suited for bank-transfer and mobile-payment methods common in university environments. First, an attendee submits their bank transaction reference and an optional screenshot via POST /api/payments — this stores the evidence against their attendees row and leaves the status as pago_pendiente (payment pending). Second, a faculty tenant_admin reviews the submitted evidence and either approves or rejects it via POST /api/payments/verify, which flips the status to confirmado or rolls it back to registrado. Only the admin whose tenantId matches the event’s tenantId can verify a given payment, preventing cross-tenant access.

POST /api/payments

Submits payment evidence for a registered attendee. The attendee must belong to the authenticated user’s account. On success, attendees.paymentReference and attendees.paymentScreenshotUrl are updated. The status field is not changed by this endpoint — it remains pago_pendiente until a tenant_admin verifies it.

Authentication

Required. Any authenticated user with a valid session. Returns 401 if no session is found.

Content-Type

multipart/form-data

Request Fields

attendeeId
string
required
UUID of the attendee record that belongs to the authenticated user. Returns 404 if the record does not exist or does not belong to session.userId.
paymentReference
string
required
The bank or mobile-payment transaction reference code provided by the payment receipt (e.g. "TRF-20241121-00842").
screenshot
File
Optional image file (JPEG, PNG, WebP, etc.) of the payment receipt or confirmation screen. If provided, it is processed with sharp (resized to a maximum of 800 px wide, re-encoded as WebP at quality 80) and stored. See the note below for storage details.
curl -X POST "https://your-domain.com/api/payments" \
  -H "Cookie: session=<your-session-cookie>" \
  -F "attendeeId=7c9e6679-7425-40de-944b-e07fc1f90ae7" \
  -F "paymentReference=TRF-20241121-00842" \
  -F "screenshot=@/path/to/receipt.jpg"

Response 200

success
boolean
true when the payment evidence has been saved.
{
  "success": true
}

Error Responses

StatusBodyReason
400{ "error": "Missing fields" }attendeeId or paymentReference is missing from the form data.
401{ "error": "Unauthorized" }No valid session found.
404{ "error": "Not found or forbidden" }Attendee does not exist or belongs to a different user.
500{ "error": "Internal Server Error" }Unexpected server or database error.
Screenshot processing and storage: uploaded images are processed with sharp — resized to a maximum width of 800 px (without enlargement) and re-encoded as WebP at quality 80 to minimize storage size. The processed file is first uploaded to Supabase Storage. If Supabase is unavailable or not configured, the file falls back to local disk at /public/uploads/payments/payment_<attendeeId>_<timestamp>.webp, and the stored URL will be a relative path (e.g. /uploads/payments/payment_7c9e..._1732190700000.webp).

POST /api/payments/verify

Allows a tenant_admin to approve or reject a pending payment submission. The admin may only act on attendees whose event belongs to their own tenant — cross-tenant verification is blocked with a 403. On approve, the attendee status is set to confirmado and the verifying admin’s ID and timestamp are recorded. On reject, the status is rolled back to registrado and the payment evidence fields are cleared, allowing the attendee to resubmit.

Authentication

Required. The session must have role = "tenant_admin". Any other role returns 401.

Request Body

attendeeId
string
required
UUID of the attendee whose payment is being reviewed.
action
string
required
Either "approve" or "reject".
  • "approve" — sets status = 'confirmado', paymentVerifiedBy = session.userId, paymentVerifiedAt = now().
  • "reject" — sets status = 'registrado', clears paymentReference and paymentScreenshotUrl, allowing the attendee to resubmit.
# Approve a payment
curl -X POST "https://your-domain.com/api/payments/verify" \
  -H "Content-Type: application/json" \
  -H "Cookie: session=<tenant-admin-session-cookie>" \
  -d '{
    "attendeeId": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
    "action": "approve"
  }'

# Reject a payment
curl -X POST "https://your-domain.com/api/payments/verify" \
  -H "Content-Type: application/json" \
  -H "Cookie: session=<tenant-admin-session-cookie>" \
  -d '{
    "attendeeId": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
    "action": "reject"
  }'

Response 200

success
boolean
true when the action has been applied.
{
  "success": true
}

Error Responses

StatusBodyReason
400{ "error": "Missing fields" }attendeeId or action is absent from the request body.
401{ "error": "Unauthorized. Solo los administradores de facultad pueden verificar pagos." }Session is missing or the authenticated user is not a tenant_admin.
403{ "error": "Forbidden. No tienes permisos para este evento." }The attendee’s event belongs to a different tenant than the admin’s tenantId.
404{ "error": "Attendee not found" }No attendee record exists for the provided attendeeId.
500{ "error": "Internal Server Error" }Unexpected server or database error.

Payment Status Flow

The table below summarises the attendees.status transitions driven by the two endpoints:
StatusMeaningTransition
registradoAttendee registered, no payment submitted.Starting state, or set by reject.
pago_pendientePayment evidence submitted, awaiting admin review.Set externally when the attendee submits; evidence saved by POST /api/payments.
confirmadoPayment verified by a tenant_admin.Set by POST /api/payments/verify with action = "approve".

Build docs developers (and LLMs) love