Settlement is a process by which a merchant transaction is paid and the platform transfers the funds into the merchant’s account. The settlement can be made into an account inside Pismo (internal transfer) or outside Pismo (external transfer).

Settlement payments are made on the same day as the scheduled payment date. This is to ensure that the settlement amount is aligned with the amount the merchant expects to receive. Although you cannot configure settlement schedules, you can however, configure payment schedules at any time and in any range of days after a sale, see the note in the Settlement scenarios section for details.

Merchant transactions are settled daily according to the settlement schedules. These settlement schedules can only be configured by Pismo and are set to occur at 7 AM GMT everyday. This ensures that settlements occur during the early hours of your time zone.

The Merchant transaction settled provides information about the settlement timeline and the amount a given merchant receives on a given day. One event is sent for each merchant who has the amount to be settled on that day.

The following scenarios illustrate timeline examples with different settlement stages, including examples of regular sales and examples of sales that include cancellation and negative balances. In these illustrations, you learn how different transactions that occur and settle at different points in time affect final settlement outcomes.

Settlement scenarios

The following acronyms for settlement schedules are used in example scenarios:

D0: payment scheduled to be settled on the same day of the sale
D1: payment scheduled to be settled one day after the sale
D2: payment scheduled to be settled two days after the sale
Dn: payment scheduled to be settled n days after the sale

📘

Notes

• Payment schedules can be configured to perform in any range of days after a sale. You can specify the amount of days it takes to settle a payment by sending first_installment_days_to_payment and n_installment_days_to_payment in the Create creditor operation endpoint.
• You can override first_installment_days_to_payment by specifying a fixed date for the first payment. See Overriding the scheduled payment date for more information.
• In all of the following scenarios, the scheduled settlement is set to occur at 7 AM GMT every day.

Scheduled settlement

1. Sale A (USD 20,000) takes place on April 22nd, and Sale B on the 23rd (USD 30,000), both are scheduled to settle in the morning of April 24th.
2. On April 24th, the merchant receives a total settlement amount of USD 50,000.

Scheduled settlements and same-day settlements

In this scenario, the following takes place:

1. Sale A (USD 20,000) occurs on April 22nd and the payment is scheduled to settle on the 24th.
2. Sale B (USD 30,000) takes place on April 23rd and the payment is scheduled for the 24th.
3. Sale C (USD 1,000) occurs on April 24th, and the payment is scheduled for the 25th.
4. Sale D (USD 2,000) takes place on the 24th, and the payment is scheduled for the 25th.
5. Therefore, on April 24th, the merchant receives the settlement amount of USD 50,000 (Sale A + B), and receives USD 3,000 (Sale C + D) on April 25th.
   Note: Sales C and D are both D0 sales; that is, they are supposed to be settled on the same day of the sale. However, since the sales occur after the settlement for the day has already taken place, payments to the merchants can only be made on the next day, which is the 25th.

Scheduled and same-day settlements plus cancellation

In this scenario, a cancellation is added to the settlement process:

1. Sale A (USD 20,000) occurs on April 22nd and is scheduled to settle on the 24th.
2. Sale B (USD 30,000) takes place on the 23rd and is also scheduled to settle on the 24th.
3. Sale C (USD 1,000) happens on the 24th and is scheduled to settle on the 25th.
4. Sale D (USD 2,000) occurs on the 24th and is scheduled to settle on the 25th.
5. Therefore, the total settlement amount for April 24th is USD 50,000 (Sale A + B).
6. However, a cancellation of USD 30,000 takes place on the 24th and is scheduled to settle on the 25th; therefore, the final settlement amount on April 25th is USD -27,000 (negative amount).

Negative balance

This scenario becomes even more complex when there is a negative balance involved. In this scenario:

1. Sale A (USD 20,000) occurs on April 22nd and is scheduled to settle on the 24th.
2. Sale B (USD 30,000) takes place on the 23rd and is also scheduled to settle on the 24th.
3. Sale C (USD 1,000) happens on the 24th and is scheduled to settle on the 25th.
4. Sale D (USD 2,000) occurs on the 24th and is scheduled to settle on the 25th.
5. Therefore, on the 24th, the amount that is settled is USD 50,000.
6. However, on April 24th, a cancellation of Sale B takes place and is scheduled to settle on the 25th.
7. On the 25th, the merchant has a negative settlement amount of USD -27,000 (Sale (C + D) - B).
8. On April 25th, Sale E (USD 5,000) occurs and is scheduled to settle on the 26th; as a result, the merchant has a negative balance of USD -22,000 (USD -27,000 + 5,000 = -22,000), and therefore will also not receive the value of the sale, as the balance was negative.

Merchant transaction settled event

As illustrated in all of the preceding scenarios, one of the complexities is in reconciling settlement values. Therefore, to accurately identify payment dates and the amount that the merchant expects to receive, Pismo provides a Merchant transaction settled event, which contains the most up-to-date information to help you reconcile and understand how much the merchant can expect to receive on the settlement date. For example, to identify the settlement amount, you use the value in settlement_amount; likewise, to find the settlement date for a transaction, use the settlement_date value.

Overriding the scheduled payment date

You can override the first_installment_days_to_payment field previously configured in Create creditor operation by providing a fixed date for the first payment. To do this, use the Request authorization endpoint to send a minimum_settlement_date in the metadata object. The following sample payload illustrates this.

{
	"mti": "0100",
	"merchant": {
		"id": "mc-12345",
		"name": "Acme Used Books",
		"city": "San Diego",
		"country": "USA",
		"category_code": "5099",
		"marketplace_id": "mkt-1234"
	},
	"amount": 10,
	"currency": "986",
	"network": "Mastercard",
	"account_id": 123456789,
	"authorization_mode": "CREDIT",
	"entry_mode": "05",
	"clearing_type": "ONLINE",
	"processing_code": "P01001",
	"number_of_installments": 2,
	"metadata": {
		"minimum_settlement_date": "2024-07-22"
	}
}

As an example of how this feature might be used, suppose you have a marketplace campaign that extends between 15 July 2024 and 21 July 2024. When scheduling the settlement for all these purchases, the merchants want the first payments to occur on 22 July 2024, instead of 10 days later as they normally would. To implement this, you would use the above endpoint with minimum_settlement_date set to "2024-07-22".

Installment plans

The retailer installment plan (interest-free installments) is created at the time of purchase confirmation. The total amount is divided into several debit transactions, each representing a separate installment to be paid by the cardholder.

In addition to installment transactions, a contract transaction is created, which serves only for internal control and does not appear on the customer's invoice.

Installments are released at the time of purchase confirmation, meaning all future installments are created and associated with the corresponding invoices as soon as the first clearing/Base II arrives.

Recalculation on the second installment

After creating the plan, the total purchase amount is divided by the number of installments. The amount of each installment is calculated at the time of authorization, taking into account possible rounding. For example, for a purchase of R$100.00 in 3 installments, the first installment could be R$33.34 and the remaining installments R$33.33, to ensure the total amount is distributed correctly.

There is no automatic recalculation of installments when the second (or subsequent) installments arrive. The amount of each installment is already set at the time of purchase and remains fixed until the end of the plan, except in cases of cancellation or advance payment.

Recurring decimal breaks

When the total purchase amount is not evenly divisible by the number of installments, a recurring decimal break occurs. In this case, the system rounds up the first installment to ensure that the sum of the installments equals the total purchase amount. For example, on a purchase of R$ 100.00 in 3 installments:

1st installment: R$ 33.34

2nd installment: R$ 33.33

3rd installment: R$ 33.33

This adjustment is made automatically by the system, with no impact on the customer or the retailer.