The payment object

You can expect the below object when you register a webhook for the following events:

• payment.failed
• payment.succeeded
• payment.refund_initiated
• payment.refunded
• payment.refund_failed
• payment.card_verified
• payment.authorized
• payment.voided

Raw sample

{
  "status": "captured",
  "id": "PAY-3C4D5E6F7A",
  "amount": 33.99,
  "amount_currency": "AED",
  "refund_amount": 0,
  "refund_status": "No refund",
  "refunds": [],
  "max_refund_amount": 33.99,
  "billing_descriptor": "Mamo*Merchant",
  "custom_data": {},
  "created_date": "2023-12-25-14-38-53",
  "subscription_id": null,
  "settlement_amount": "31.99",
  "settlement_currency": "AED",
  "settlement_date": "2024-01-01",
  "customer_details": {
    "name": "",
    "email": "[email protected]",
    "phone_number": "-",
    "comment": "-"
  },
  "payment_method": {
    "card_id": null,
    "method": "Card",
    "type": "CREDIT VISA",
    "card_holder_name": "John Doe",
    "card_last4": "1111",
    "card_expiry_month": "12",
    "card_expiry_year": "2028",
    "origin": "International card"
  },
  "settlement_fee": "AED 1.90",
  "settlement_vat": "AED 0.10",
  "payment_link_id": "MB-LINK-5E6F7A8B9C",
  "payment_link_url": "https://sandbox.dev.business.mamopay.com/pay/acme-chocolates-4d5e6f",
  "external_id": null,
  "error_code": null,
  "error_message": null,
  "next_payment_date": null,
  "event_type": "payment.succeeded"
}

Field descriptions

Payment status lifecycle

The status field tells you where a payment is in its lifecycle and, crucially, whether money has actually been received. On webhooks the status is reported raw — it is never remapped — so an authorized hold arrives as authorized (not captured) and a payment voided by Mamo's fraud screening arrives as voided (not failed). Note that confirmation_required and processing do not trigger a webhook, so you will not receive this object for those states; a payment you hear about via webhook has reached captured, failed, authorized, card_verified, or voided.

Refunds don't change status: a refunded payment stays captured, so you can refund it again up to max_refund_amount. Track refunds with refund_status (initiated, success, failed, or No refund), refund_amount, max_refund_amount and refunds[]. Payments made before February 2022 may still show the legacy values refund_initiated or refunded.

📘

Authorize vs. capture (hold_and_charge_later)

On a normal payment link the charge is captured immediately, so a successful payment goes straight to captured and the funds are received.

On a payment link configured with hold_and_charge_later, the payment is only authorized first: the amount is placed on hold on the customer's card and the charge sits in authorized until you capture it later. You can release the hold with Reverse payment, which moves the charge to voided; no webhook is sent for that, so use the Reverse Payment response as your confirmation. On webhooks these states are reported raw — an authorized hold is sent as authorized (not captured) — so rely on the status together with the link configuration to know whether a given payment is a hold or a completed capture.

What differs per event

The raw sample above is a payment.succeeded payload. Other events carry the same object shape — only these fields change:

📘

Marketplace / split payments

This object does not include payouts_share — the split amount is available on the payment link object instead. For a split payment, the recipient's share is credited to their recipient ledger on the payment's settlement date (at capture if your account settles same-day); it is paid out to their bank account later on a schedule (by default monthly). Use Fetch recipient balance to check a recipient's accrued ledger balance.