Pay Later Account

Problem

Design PayLaterAccount for one user. It accepts cash orders without creating debt and Pay Later orders against one credit limit, then tracks settlement, overdue defaults, and blacklist eligibility through a sequential series of dated calls.

Requirements

Cash orders. After the overdue refresh, a valid cash order returns true without creating a due, consuming available credit, or independently changing the default count.
Pay Later orders. When the amount is at most available credit and the account is not blacklisted, a Pay Later order returns true, creates one unpaid due, and reduces available credit by the amount.
Rejected financing. A Pay Later order returns false when its amount exceeds available credit or the account is blacklisted. Rejection creates no order or due and does not change available credit, although the overdue refresh still occurs first.
Due day. A successful Pay Later order made on purchaseDay is due on purchaseDay + 30 and remains on time through that day.
Default recording. At the start of each call, every unpaid due whose due day is less than the operation day records one historical default exactly once.
Full settlement. clearDue settles the specified unpaid due in full and restores its amount to available credit.
Default history. Settling a due after its default was recorded does not reduce the historical default count.
Blacklist threshold. Recording the third historical default activates the blacklist, and later Pay Later orders return false.
Permanent blacklist. Once activated, the blacklist remains active.
Cash after blacklist. Valid cash orders continue to return true after the blacklist activates.

API

Signature	Returns	Behavior
`PayLaterAccount(initialCreditLimit: integer)`	Not applicable	Creates an account with the full limit available, no dues, no defaults, and no blacklist.
`placeOrder(orderId: string, amount: integer, paymentMode: string, purchaseDay: integer)`	`boolean`	Refreshes overdue state for `purchaseDay`, then attempts the order using the requirements above.
`clearDue(orderId: string, clearingDay: integer)`	`void`	Refreshes overdue state for `clearingDay`, then settles the referenced unpaid Pay Later due.

Examples

Step	Operation	Result
1	`PayLaterAccount(500)`	A new account with 500 available credit.
2	`placeOrder("cash-1", 700, "cash", 0)`	`true`; available credit remains 500.
3	`placeOrder("later-1", 300, "pay-later", 0)`	`true`; available credit becomes 200 and the due day is 30.
4	`placeOrder("later-2", 250, "pay-later", 1)`	`false`; available credit remains 200.
5	`clearDue("later-1", 30)`	The due is settled on time and available credit returns to 500.

Three Pay Later orders made on day 0 are all overdue when the next call occurs on day 31. That call records three defaults before performing its requested operation, so later Pay Later orders fail while cash orders still succeed.

Constraints

0 <= initialCreditLimit <= 1,000,000,000.
Each orderId passed to placeOrder is a unique, non-empty ASCII string of at most 64 characters.
1 <= amount <= 1,000,000,000.
paymentMode is the case-sensitive string "cash" or "pay-later".
Operation days are integers from 0 through 1,000,000,000 and are nondecreasing across all calls.
clearDue receives the ID of an existing unpaid Pay Later due.
At most 100 public method calls occur in one testcase.

Notes

Calls are sequential and methods do not wait. Amounts are integer minor currency units. Interest, fees, fractions, overflow, negative balances, and behavior outside the stated input constraints are not judged.