Test scheduling a future dated bill payment

The contract this flow keeps

The payment must not go out today, and it has to be recorded in a way the customer can find and change later.

• The payee and source - both selected explicitly, since a bill paid from the wrong account is still a wrong payment.
• The future date is recognised - a hint confirming that future dates are scheduled rather than sent immediately.
• The payment is listed as scheduled - in a dedicated scheduled payments card, not in a sent history.
• The date is on the record - so the customer can see when it will happen.

Asserting the hint before submitting is what proves the interface distinguishes the two cases. A form that accepts a future date and pays immediately would satisfy every other assertion about the payment existing.

The objective in plain English

The payee is asserted with its masked account number on the scheduled record, which ties the payment to a specific biller account rather than a name.

---
mode: testing
url: https://my-testing-repo-main.vercel.app/chase-clone-app?reset=true
max_steps: 50
tags: [chase, banking, payments]
---

# Chaise Bank 23.3: Bill pay scheduling

Catalog objective: schedule a future dated bill payment.
Key assertion: the payment is listed as scheduled with its date.

## Sign in
Type "priya.nair" into "Username", "Bank2026!" into "Password", click "Sign in", type "483921" into "One-time code", and click "Verify and sign in".

## Set the payment up
Go to https://my-testing-repo-main.vercel.app/chase-clone-app/billpay, select "Lone Star Power" in "Payee", select the Total Checking account in "Pay from", and type "136.42" into "Amount".

## Choose a future date
Set "Send on" to "2026-09-30" and verify the hint says future dates are scheduled rather than sent today.

## Verify it is listed as scheduled
Click "Schedule payment" and verify the "Scheduled payments (1)" card lists "Lone Star Power ••••4471" for "$136.42" with the note "Send on 2026-09-30".

The scheduled payments count is part of the final assertion, which proves exactly one payment was scheduled rather than a duplicate pair.

Assertion by assertion

A login, a setup, a date and the record.

A scheduled payment that confirms but does not appear in a list is a payment the customer cannot cancel, which is worse than one that fails to schedule at all.

Putting it in CI

kane-cli testmd run tests/chase/bill-pay-scheduling_test.md

Add a same-day variant, since the correct behaviour there is to send rather than schedule and the boundary between them is the interesting part.

Deferred actions are hard to observe and easy to leave uncovered. Running flows asynchronously covers unattended checks, and generating the same-day variant covers the other side of the boundary.