P2PPay Company API (Peer Matching) (1.0.0)

Retrieves the list of available PayIn channels for the authenticated company

Retrieves the list of available PayOut channels for the authenticated company

Retrieves per-channel configuration (min/max amount, allowed exact amounts) for PayIn channels available to the authenticated company. Useful before calling POST /payIn/create to pre-validate amounts.

Retrieves per-channel configuration (min/max amount, allowed exact amounts) for PayOut channels available to the authenticated company.

Retrieves the list of available PayIn channels for the authenticated company

Retrieves per-channel configuration (min/max amount, allowed exact amounts) for PayIn channels available to the authenticated company. Useful before calling POST /payIn/create to pre-validate amounts.

Creates a new peer-matching PayIn transaction (deposit/top-up).

The platform reserves a destination peer bank account for the company and returns it in the response (bank, accountNumber, peerAccountName). The end user must transfer the exact returned amount from peerBank/peerAccountNumber, then the company calls POST /slip/upload with the bank-slip image to reconcile the transaction.

Minimum Amount: 100

Peer-Matching Notes:

• peerBank and peerAccountNumber identify the sender account the end user will transfer from. Providing them improves auto-match accuracy.
• The platform may adjust the requested amount by small cents so each pending peer transaction has a unique (destination, amount) pair. Use the amount field in the response as the amount the user must send.

Signature Calculation:

1. Sort all request body fields (except signature) by key alphabetically
2. Create payload string: key1=value1key2=value2...
3. Compute MD5 hash of payload + signKey
4. Use hex string of the hash as signature

Uploads a bank-slip image to reconcile a pending peer-matching PayIn transaction. The upload is multipart/form-data with a single image file field.

Processing steps (server-side):

1. Store the image and create a bank_slip_image record with status PENDING plus an associated transaction_evidence record.
2. If slip verification is enabled, extract the QR from the slip and call the slip-verify provider to get the decoded transfer data.
3. Reject duplicate slips (same verified slip hash) — returns DUP MATCHED and the evidence is rejected.
4. Validate that the decoded destination account matches one of the company's configured destination accounts (skipped for peer-only companies where destinations are dynamic).
5. Attempt to auto-match the slip to a pending BankExpect for the company using amount + peerBank + peerAccountNumber + time window. On a unique match, the corresponding PayIn transaction is confirmed and a status callback is scheduled.

Auto-match outcomes (recorded on the evidence / returned via later status):

• MATCHED <externalRefId> — slip bound to a pending transaction
• NOT MATCH - NO TXCANDIDATE FOUND
• NOT MATCH - MULTIPLE TXCANDIDATE FOUND
• NOT MATCH - OUT OF TIME (N hours ago) — slip timestamp older than 24h
• NOT MATCH - ALREADY MATCHED <externalRefId>
• NOT MATCH - REFUNDED

The HTTP response returns the stored image(s) metadata. The final match result is reported asynchronously via POST /status/{refId} or the status callback.

Retrieves the list of available PayOut channels for the authenticated company

Retrieves per-channel configuration (min/max amount, allowed exact amounts) for PayOut channels available to the authenticated company.

Creates a new peer-matching PayOut transaction (withdrawal).

peerBank and peerAccountNumber are the destination account owned by the end user / member.

Minimum Amount: 300

Signature Calculation:

1. Sort all request body fields (except signature) by key alphabetically
2. Create payload string: key1=value1key2=value2...
3. Compute MD5 hash of payload + signKey
4. Use hex string of the hash as signature

Returns the peer-match fulfillment state for a peer-matching PayOut (withdraw) transaction, identified by internal refId.

Use this when you need to see which peer deposits are being used to fulfill a withdraw order and how much is still outstanding. The regular POST /status/{refId} endpoint only returns top-level transaction state; this endpoint adds the underlying PeerWithdrawRequest accounting (amount / matchedAmount / pendingAmount / remainingAmount) plus each PeerToPeerMatch that has been attached so far.

Accounting semantics:

• amount — total amount the platform is trying to fulfill from peers
• matchedAmount — amount already confirmed by peer deposits
• pendingAmount — amount locked to PENDING matches awaiting slip confirmation
• remainingAmount = amount - matchedAmount - pendingAmount

Match statuses (peerMatches[].status):

• PENDING — deposit reserved against this withdraw, awaiting slip confirmation
• CONFIRMED — deposit slip verified, amount added to matchedAmount
• REJECTED — match cancelled (e.g. slip verification failed)
• EXPIRED — slip window passed without confirmation; amount released

Withdraw request statuses (peerWithdrawRequest.status):

• OPEN — still accepting new matches
• FULFILLED — fully covered (no more matches will be created)
• STALE — expired without full fulfillment

Privacy / compactness: Only the destination account (destBank / destAccountNumber) the peer depositor paid to, and a signed, time-limited slipImageUrl pointing at the uploaded slip, are returned per match. Counterparty (depositor) identifiers, member info, the raw slip QR string, and the full slip-verify JSON are intentionally omitted — this endpoint is designed to be compact and cheap to poll; use the admin peer-monitor API for full forensics.

Same as POST /payOut/peerMatches/{refId} but looks up the PayOut by the external reference ID originally provided by the company when the transaction was created.

Uploads a bank-slip image to reconcile a pending peer-matching PayIn transaction. The upload is multipart/form-data with a single image file field.

Processing steps (server-side):

1. Store the image and create a bank_slip_image record with status PENDING plus an associated transaction_evidence record.
2. If slip verification is enabled, extract the QR from the slip and call the slip-verify provider to get the decoded transfer data.
3. Reject duplicate slips (same verified slip hash) — returns DUP MATCHED and the evidence is rejected.
4. Validate that the decoded destination account matches one of the company's configured destination accounts (skipped for peer-only companies where destinations are dynamic).
5. Attempt to auto-match the slip to a pending BankExpect for the company using amount + peerBank + peerAccountNumber + time window. On a unique match, the corresponding PayIn transaction is confirmed and a status callback is scheduled.

Auto-match outcomes (recorded on the evidence / returned via later status):

• MATCHED <externalRefId> — slip bound to a pending transaction
• NOT MATCH - NO TXCANDIDATE FOUND
• NOT MATCH - MULTIPLE TXCANDIDATE FOUND
• NOT MATCH - OUT OF TIME (N hours ago) — slip timestamp older than 24h
• NOT MATCH - ALREADY MATCHED <externalRefId>
• NOT MATCH - REFUNDED

The HTTP response returns the stored image(s) metadata. The final match result is reported asynchronously via POST /status/{refId} or the status callback.

Manually triggers a status callback for a transaction using the internal reference ID (refId)

Manually triggers a status callback for a transaction using the external reference ID (externalRefId provided by company)

Retrieves the current status of a transaction using the internal reference ID (refId)

Retrieves the current status of a transaction using the external reference ID (externalRefId provided by company)

Returns the peer-match fulfillment state for a peer-matching PayOut (withdraw) transaction, identified by internal refId.

Use this when you need to see which peer deposits are being used to fulfill a withdraw order and how much is still outstanding. The regular POST /status/{refId} endpoint only returns top-level transaction state; this endpoint adds the underlying PeerWithdrawRequest accounting (amount / matchedAmount / pendingAmount / remainingAmount) plus each PeerToPeerMatch that has been attached so far.

Accounting semantics:

• amount — total amount the platform is trying to fulfill from peers
• matchedAmount — amount already confirmed by peer deposits
• pendingAmount — amount locked to PENDING matches awaiting slip confirmation
• remainingAmount = amount - matchedAmount - pendingAmount

Match statuses (peerMatches[].status):

• PENDING — deposit reserved against this withdraw, awaiting slip confirmation
• CONFIRMED — deposit slip verified, amount added to matchedAmount
• REJECTED — match cancelled (e.g. slip verification failed)
• EXPIRED — slip window passed without confirmation; amount released

Withdraw request statuses (peerWithdrawRequest.status):

• OPEN — still accepting new matches
• FULFILLED — fully covered (no more matches will be created)
• STALE — expired without full fulfillment

Privacy / compactness: Only the destination account (destBank / destAccountNumber) the peer depositor paid to, and a signed, time-limited slipImageUrl pointing at the uploaded slip, are returned per match. Counterparty (depositor) identifiers, member info, the raw slip QR string, and the full slip-verify JSON are intentionally omitted — this endpoint is designed to be compact and cheap to poll; use the admin peer-monitor API for full forensics.

Same as POST /payOut/peerMatches/{refId} but looks up the PayOut by the external reference ID originally provided by the company when the transaction was created.

Retrieves balance information for all active company accounts (PAYIN and PAYOUT)

Retrieves the list of supported bank codes for transactions