Payment
| This document is better viewed at https://docs.openzeppelin.com/contracts/api/payment |
Utilities related to sending and receiving payments. Examples are PullPayment, which implements the best security practices when sending funds to third parties, and PaymentSplitter to receive incoming payments among a number of beneficiaries.
| When transferring funds to and from untrusted third parties, there is always a security risk of reentrancy. If you would like to learn more about this and ways to protect against it, check out our blog post Reentrancy After Istanbul. |
Utilities
PaymentSplitter
This contract allows to split Ether payments among a group of accounts. The sender does not need to be aware that the Ether will be split in this way, since it is handled transparently by the contract.
The split can be in equal parts or in any other arbitrary proportion. The way this is specified is by assigning each account to a number of shares. Of all the Ether that this contract receives, each account will then be able to claim an amount proportional to the percentage of total shares they were assigned.
PaymentSplitter follows a pull payment model. This means that payments are not automatically forwarded to the
accounts but kept in this contract, and the actual transfer is triggered as a separate step by calling the release
function.
constructor(address[] payees, uint256[] shares_) public
Creates an instance of PaymentSplitter where each account in payees is assigned the number of shares at
the matching position in the shares array.
All addresses in payees must be non-zero. Both arrays must have the same non-zero length, and there must be no
duplicates in payees.
receive() external
The Ether received will be logged with PaymentReceived events. Note that these events are not fully
reliable: it’s possible for a contract to receive Ether without triggering this function. This only affects the
reliability of the events, and not the actual splitting of Ether.
To learn more about this see the Solidity documentation for fallback functions.
released(address account) → uint256 public
Getter for the amount of Ether already released to a payee.
PullPayment
Simple implementation of a pull-payment strategy, where the paying contract doesn’t interact directly with the receiver account, which must withdraw its payments itself.
Pull-payments are often considered the best practice when it comes to sending Ether, security-wise. It prevents recipients from blocking execution, and eliminates reentrancy concerns.
| If you would like to learn more about reentrancy and alternative ways to protect against it, check out our blog post Reentrancy After Istanbul. |
To use, derive from the PullPayment contract, and use _asyncTransfer
instead of Solidity’s transfer function. Payees can query their due
payments with payments, and retrieve them with withdrawPayments.
withdrawPayments(address payable payee) public
Withdraw accumulated payments, forwarding all gas to the recipient.
Note that any account can call this function, not just the payee.
This means that contracts unaware of the PullPayment protocol can still
receive funds this way, by having a separate account call
withdrawPayments.
Forwarding all gas opens the door to reentrancy vulnerabilities.
Make sure you trust the recipient, or are either following the
checks-effects-interactions pattern or using ReentrancyGuard.
|
_asyncTransfer(address dest, uint256 amount) internal
Called by the payer to store the sent amount as credit to be pulled.
Funds sent in this way are stored in an intermediate Escrow contract, so
there is no danger of them being spent before withdrawal.
Escrow
Escrow
Base escrow contract, holds funds designated for a payee until they withdraw them.
Intended usage: This contract (and derived escrow contracts) should be a
standalone contract, that only interacts with the contract that instantiated
it. That way, it is guaranteed that all Ether will be handled according to
the Escrow rules, and there is no need to check for payable functions or
transfers in the inheritance tree. The contract that uses the escrow as its
payment method should be its owner, and provide public methods redirecting
to the escrow’s deposit and withdraw.
withdraw(address payable payee) public
Withdraw accumulated balance for a payee, forwarding all gas to the recipient.
Forwarding all gas opens the door to reentrancy vulnerabilities.
Make sure you trust the recipient, or are either following the
checks-effects-interactions pattern or using ReentrancyGuard.
|
ConditionalEscrow
Base abstract escrow to only allow withdrawal if a condition is met.
Intended usage: See Escrow. Same usage guidelines apply here.
RefundEscrow
Escrow that holds funds for a beneficiary, deposited from multiple
parties.
Intended usage: See Escrow. Same usage guidelines apply here.
The owner account (that is, the contract that instantiates this
contract) may deposit, close the deposit period, and allow for either
withdrawal by the beneficiary, or refunds to the depositors. All interactions
with RefundEscrow will be made through the owner contract.