Zum Hauptinhalt springen

Documentation Index

Fetch the complete documentation index at: https://docs.getovra.com/llms.txt

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

Eine Transaktion ist die Source of Truth für „Geld bewegt”. Jede erfolgreiche Belastung — MPP, CUA oder simuliert — schreibt eine transactions-Row gebunden an Agent und Intent. Transaktionen sind post-completion immutable; Refunds und Disputes schreiben neue Rows die auf das Original referenzieren.

​
Das Transaktions-Modell

FeldTypBeschreibung
idtx_*Identifier
intentIdint_*Autorisierender Intent (immer present in v1.2)
agentIdag_*Owning Agent
cardIdca_*Belastete Karte
amountEurosnumberEUR-Betrag
currencystringImmer EUR
merchantstringMerchant-Name
merchantMccstringMCC-Code
merchantCountrystringISO 3166-1 Alpha-2
railenummpp · cua · simulate
statusenumpending → completed · failed · reversed
verifiedbooleanTrue nach /intents/:id/verify
mismatchbooleanTrue wenn Actual über amountTolerancePercent abwich
issuerAuthorizationIdstring?Card-Issuer-Auth-Reference
issuerSettlementIdstring?Card-Issuer-Settlement-Reference
createdAtISO 8601UTC

​
Lebenszyklus

pending → completed     (Auth + Settlement OK)
pending → failed        (Decline oder Downstream-Error)
completed → reversed    (Refund applied)
Für MPP emittiert die Rail mpp.transaction.completed bei Erfolg. Für CUA und Card-Auths siehst du transaction.authorization gefolgt von transaction.settlement, dann transaction.completed.

​
Transaktionen auflisten

curl "https://api.getovra.com/transactions?agentId=ag_...&limit=50" \
  -H "Authorization: Bearer $OVRA_API_KEY"
Cursor-paginated. Filter nach Agent, Card, Intent, Merchant, Status, Date-Range.

​
Refunds

curl -X POST https://api.getovra.com/refunds \
  -H "Authorization: Bearer $OVRA_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "transactionId": "tx_...",
    "amountEuros": 4.51,
    "reason": "Subscription gekündigt"
  }'
Der Card-Issuer-Webhook treibt die Reversal — wenn settled, flippt der Status der ursprünglichen Transaktion auf reversed und transaction.refunded feuert.

​
Disputes

Siehe Disputes. Eine Transaktion kann maximal einen offenen Dispute haben. Disputes tragen Evidence (Receipt, Shipping, Communication etc.) und einen Status-FSM.

​
Memos und Comments

# Memo hinzufügen (single Field, ersetzt existierendes)
curl -X PATCH https://api.getovra.com/transactions/tx_.../memo \
  -H "Authorization: Bearer $OVRA_API_KEY" \
  -d '{ "memo": "Q2-Marketing-Budget" }'

# Comment anhängen (audit-logged)
curl -X POST https://api.getovra.com/transactions/tx_.../comments \
  -H "Authorization: Bearer $OVRA_API_KEY" \
  -d '{ "comment": "Von Finance reviewed" }'

​
Webhooks

EventWann
transaction.createdRow inserted
transaction.authorizationCard-Auth akzeptiert
transaction.settlementKarte gecleart
transaction.completedFinal State — Auth + Settlement OK
transaction.declinedAuthorization abgelehnt
transaction.settledSettled (legacy Alias)
transaction.updatedMemo oder Status geändert
transaction.refundedRefund gepostet
mpp.transaction.completedMPP-Rail-Settle
verification.mismatchActual divergierte über Toleranz

​
Plan-Tier-History-Retention

PlanHistory
Free30 Tage
Starter90 Tage
Business365 Tage
Enterprise5 Jahre
Ältere Transaktionen werden automatisch gepruned; Export via /audit/export für Long-Term-Retention.

​
Surfaces

SurfaceCapability
REST/transactions, /transactions/:id, /refunds
SDKovra.transactions.*, ovra.refunds.*
MCPovra_transaction (read + memo)
Dashboard/dashboard/activity (konsolidierte View)

​
Weiter

Disputes

Eine Transaktion anfechten.

Intelligenz

Analytics, Anomaly-Detection, Audit über Transaktionen.

Webhooks

In Echtzeit auf Transaction-Events reagieren.