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

Raw sample

{
  "status": "captured",
  "id": "PAY-D65B203ABD",
  "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,
    "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-1EC52247EE",
  "payment_link_url": "https://staging.business.mamopay.com/pay/mamosandbox-8acfdf",
  "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 released hold 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 (refund events carry refund_initiated / 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. The hold can be released, which moves the charge to voided. On webhooks these states are reported raw — an authorized hold is sent as authorized (not captured) and a released hold as voided (not failed) — 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 when the payment is captured; 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.