Asian payment aggregator covering e-wallets, QR, and bank transfers (Philippines PHP, Korea KRW). The payer pays from their e-wallet (GCash, Maya, GrabPay), scans a QR (QRPH), or receives a bank payout. Deposits are processed through OFApay's hosted payment page; payouts are sent directly to the recipient's wallet/bank. Supports Pay-In and Pay-Out.Operations: Pay-In ✓ | Pay-Out ✓ | Webhook ✓ Processing: Asynchronous - Pay-In redirects the payer to OFApay's hosted payment page (or renders a QR); final status for both flows arrives via webhook Payment type: E-wallet / QR / Bank transfer
Account-per-method: OFApay is configured as one account per payment method. Each account carries its own scode (MID) and signature key, tagged with the method it serves (GCash, Maya, …). The paymentMethod you send on the cashier call selects which account is used. The currency and routing (paytype) are fixed per method and derived server-side - you do not send paytype.
Currency is fixed per method: GCash / Maya / GrabPay / QRPH → PHP, Bank Payouts → KRW.
The OFApay method this account serves (GCash, Maya, GrabPay, QRPH, Bank Payouts)
scode*
OFApay Merchant ID (MID). Provided by OFApay per method
apiKey*
OFApay signature key used to sign requests and verify callbacks (MD5). Stored per brand, encrypted at rest, and masked in the back office
siteUrl
Default return URL - OFApay redirects the payer here after completing a Pay-In on the hosted page. Used when the transaction does not send its own siteUrl
webhookUrl*
Your HTTPS endpoint for transaction status updates
The cashier call does not move funds directly. It creates a transaction and returns a paymentUrl (OFApay's hosted payment page). Redirect the payer to that URL, where they confirm the payment in their e-wallet or scan the QR. The final status arrives later via webhook.
Payer identity comes from the user token.firstName, lastName, and email are taken from the authenticated user (x-user-token) and must not be sent in the body.
Pay-Out is a direct API call - no hosted page and no paymentUrl. Mozarto sends the payout to the recipient's wallet or bank account. The final status arrives via webhook.
Mozarto calls your webhookUrl when the transaction reaches a final state. OFApay notifies Mozarto on its own callback URL first; Mozarto then forwards a normalized notification to you. The payload is identical for Pay-In and Pay-Out - it carries no flow indicator. Match transaction_id against the cashier call to distinguish them. Non-final statuses (e.g. still processing) are acknowledged but not forwarded.
For some channels OFApay does not know the payer's wallet details at request time. When the payer completes the payment, OFApay calls Mozarto's payer-info endpoint with the payer's payeraccount and payername; Mozarto stores these against the transaction. This is internal to Mozarto and is not forwarded to your webhook.
The cashier call returns an error when the transaction cannot be set up. Payment declines are reported later through the webhook with transaction_status: "Failed", not on this call.