Seller payouts are disabled by default. Do not enable them until the operator has PayPal Payouts approval and has validated recipient, tax, sanctions, recovery, and reconciliation procedures.
The standard deployment has no automatic payout schedule, promised arrival time, or published payout fee. A saved bank account is only a future destination and submitting seller verification does not move money.

​
What is implemented

  • Customer payments, refunds, and disputes are processed through the central PayPal account.
  • Each successful order updates the organization’s internal seller-payable ledger.
  • Seller verification collects identity and Indian bank details for review.
  • Finance exposes the transactions behind the payable for reconciliation.
  • A feature-gated PayPal Payouts integration can create idempotent payout attempts, reconcile item webhooks, retry eligible failures, and record the fee actually returned by PayPal.

​
What is not implemented

  • Bank-account ownership verification through a banking partner
  • Sending money to the saved Indian bank account
  • Treating an arbitrary external transfer as a reconciled OurPay payout
  • Automatic tax withholding, payout tax forms, or tax filing
The backend rejects PayPal payout-account creation while payouts are disabled. Enabling central PayPal collection is not a workaround: PayPal Orders and PayPal Payouts are separate products.

​
Feature-gated PayPal payouts

Set OURPAY_PAYPAL_PAYOUTS_ENABLED=true only after PayPal has enabled Payouts for the operator account. A payout goes to the email or other recipient identifier saved on the PayPal payout account; it does not use the saved bank destination. OurPay cannot know the exact payout fee before PayPal processes the item, so it does not estimate or silently absorb one. When PayPal returns payout_item_fee, OurPay records a processor-fee transaction and an equal seller-ledger debit. Repeated webhooks and reconciliation runs use the PayPal payout item ID to avoid charging the same fee twice. Because the fee is known after the transfer starts, it can appear as a post-payout Seller Payable adjustment and reduce a later payout. If PayPal returns, refunds, reverses, blocks, denies, or cancels an item, OurPay releases the reserved payout back to Seller Payable exactly once. A fee remains seller-paid only when PayPal actually reports it. Retryable failures stay reserved while OurPay retries them; after the configured attempt limit, OurPay releases the payout instead of leaving the seller balance locked.

​
Manual transfers during this phase

The deployment operator may decide to settle a seller externally, but that is an operational action outside the current OurPay payout lifecycle. If you do this:
  1. Verify the seller and destination under your own compliance process.
  2. Reconcile the exact currency and amount against the organization’s ledger.
  3. Retain transfer evidence and any required tax documentation.
  4. Account for the fact that OurPay will still show the original payable until a supported payout record is introduced.
Do not promise that a manual transfer is tracked, reversible, or protected by OurPay. Refunds and disputes can reduce the seller’s eventual entitlement after the original sale.

​
Payout boundary

The payout rail remains separate from payment acceptance. It creates an auditable payout transaction, reduces Seller Payable exactly once, tracks attempts and failures, and preserves the connection to original ledger entries. Finance continues to label the amount Seller Payable because provider availability, post-payout fees, refunds, and disputes can still change it. See Seller verification and bank details for the information currently collected and Seller payable and fees for the ledger calculation.