I tried to create a PR (#10738) to address this, but the fixes cascaded without end. Most of the code that ended up out of compliance was in tests, where failure would be detected appropriately. But adding the improvements to the types would have required adding // @ts-expect-error ts says payment might be null in hundreds of places.

The few places where the changes would have been in production code mostly would have added an assertion that would have caught the error a few lines early, but it would have already been handled cleanly.

I'll close these PRs and Issues in a few days if there's no outcry or suggestions for a better solution.

cc: @markm, @turadg

We should do our best to make the types accurate. If so much code assumes the promise must resolve to a Payment, and we deem it too much effort to correct them, we should consider changing the implementation so it works as documented.

returns a promise for the Payment corresponding to the indicated keyword

We can make it throw when it can't return a promise for a payment. In cases were the caller isn't certain that the keyword exists, it can use getPayouts() instead.