POST
/
payouts
/
bulk

Bulk payouts operation allows you to initiate multiple payouts for asynchronous processing. Read more about Payouts.

  • Bulk requests with more than 20 payout transactions may be rejected by pawaPay.
  • This API call is idempotent, which means it is safe to submit a request with the same payoutId multiple times.
  • Duplicate requests with the same payoutId will be ignored with the DUPLICATE_IGNORED status.
  • Since the request can be rejected, you must check the status code in the response for each submitted request. The rejectionReason in the response will contain information about the reason of the rejection.
  • Callback will be delivered separately for each payout in the bulk request as the payouts are resolved to their final status.

Each individual request can get one of the statuses on initiation:

StatusDescription
ACCEPTEDYesThe payout request has been accepted by pawaPay for processing.
ENQUEUEDYesThe payout request has been accepted, but has been enqueued for processing later. Read more about enqueued payouts.
REJECTEDNoThe payout request has been rejected. See rejectionReason for details.
DUPLICATE_IGNOREDNoThe payout request has been ignored as a duplicate of an already accepted payout request. Duplication logic relies upon payoutId.

How do i find out the final statuses of these payouts?

As the pawaPay Merchant API is an asynchronous API, you can find out the final status of the accepted payout by either:

Headers related to signatures must only be included if you have enabled “Only accept signed requests”. Read more about it from the pawaPay Dashboard documentation.

Authorizations

Authorization
string
headerrequired

Headers

Content-Digest
string

SHA-256 or SHA-512 hash of the request body.

Signature
string

Signature of the request according to RFC-9421.

Signature-Input
string

Signature-Input according to RFC-9421.

Accept-Signature
string

Expected signature algorithm of the response according to RFC-9421.

Accept-Digest
string

Expected digest algorithm of the response according to RFC-9421.

Body

application/json · object[]
payoutId
string
required

A UUIDv4 based ID specified by you, that uniquely identifies the payout.

Required string length: 36
amount
string
required

The amount to be collected (deposit) or disbursed (payout or refund).

Amount must follow below requirements or the request will be rejected:

  • Between zero and two decimal places can be supplied, depending on what the specific MMO supports. Learn about all MMO supported decimal places.
  • The minimum and maximum amount depends on the limits of the specific MMO. You can find them from the Active Configuration endpoint.
  • Leading zeroes are not permitted except where the value is less than 1. For any value less than one, one and only one leading zero must be supplied.
  • Trailing zeroes are permitted.

Valid examples: 5, 5.0, 5.00, 5.5, 5.55, 5555555, 0.5

Not valid examples: 5., 5.555, 5555555555555555555, .5, -5.5, 00.5, 00.00, 00001.32

Required string length: 1 - 23
currency
string
required

The currency in which the amount is specified.

Format must be the ISO 4217 three character currency code in upper case. Read more from Wikipedia.

You can find all the supported currencies that the specific correspondent supports from here.

The active configuration endpoint provides the list of correspondents configured for your account together with the currencies.

country
string

The country in which the MMO operates.

Format is ISO 3166-1 alpha-3, three character country code in upper case. Read more from Wikipedia.

correspondent
string
required

The correspondent code refers to the specific MMO that the specified phone number (MSISDN) has an active mobile money wallet with.

You can find all the supported correspondents listed here.

The active configuration endpoint provides the list of correspondents configured for your account.

You can use the predict correspondent enpoint to predict the correct correspondent to use based on the phone number (MSISDN).

recipient
object
required

The phone number (MSISDN) of the recipient or payer must be specified as the value of the address.

customerTimestamp
string
required

The timestamp for when you initiated the payout process. Format defined by 'date-time' in RFC3339 section 5.6 from IETF

statementDescription
string
required

Short description for the transaction. Depending on the specific MMO performing the transaction this message may be visible to the customer in the SMS receipt or within their transaction history.

Must be between 4 and 22 alphanumeric characters.

Required string length: 4 - 22
metadata
object[]

A list of metadata that you can attach to the payment for providing additional context about the payment. For example, adding orderId to indicate for which order this payment was for or customerId to know which customer this payment pertains to.

Metadata will not be visible to the customer that is party to this payment. It will be visible in the pawaPay Dashboard on the payment details page and in your financial statements as a JSON object to support automated reconciliation. It is also possible to search for recent payments in the pawaPay Dashboard using global search based on the values of metadata.

Up to 10 metadata fields can be attached to a payment.

Response

200 - application/json
payoutId
string
required

The payoutId of the payout transaction.

Required string length: 36
status
enum<string>
required

Possible payout initiation statuses:

  • ACCEPTED - The payout request has been accepted by pawaPay for processing.
  • ENQUEUED - The payout request has been accepted, but has been enqueued for processing later. Read more about enqueued payouts.
  • REJECTED - The payout request has been rejected by pawaPay. See rejectionReason for details.
  • DUPLICATE_IGNORED - The payout request has been ignored as a duplicate of an already accepted payout request. Duplication logic relies upon payoutId.
Available options:
ACCEPTED,
ENQUEUED,
REJECTED,
DUPLICATE_IGNORED
created
string

The timestamp of when the payout was created in the pawaPay platform. Format defined by 'date-time' in RFC3339 section 5.6 from IETF

rejectionReason
object