[agedd]

Summary of changes

• Add a basic Pay Later button (XML view) to the existing payment button stack, following the same pattern as the PayPal and Venmo buttons.

Screen_recording_20261014_114913.webm

AI Usage

Which AI Agent Was Used?

• Copilot
• Claude
• Other (Type Name Here)

How was AI used?
unit test generation and xml asset loading

Estimated AI Code Contribution

• less than 30%
• 30 - 60%
• 60 - 100%

Checklist

• [ ] Added a changelog entry
• Tested and confirmed payment flows affected by this change are functioning as expected

Authors

List GitHub usernames for everyone who contributed to this pull request.

• @agedd

[saralvasquez]

This generally looks great! A couple high level questions I think are worth asking

• The code for the pay later button is basically the same as that PayPalButton code. Is there any way to extract out a base class or something to reduce the amount of duplicated code?
• I noticed there weren't any analytics in here. Are those getting added later?

[saralvasquez]

Op also looks like there are lint errors somewhere

[agedd]

This generally looks great! A couple high level questions I think are worth asking

• The code for the pay later button is basically the same as that PayPalButton code. Is there any way to extract out a base class or something to reduce the amount of duplicated code?
• I noticed there weren't any analytics in here. Are those getting added later?

ah yep, agreed. i pulled the color/style mapping into a shared PaymentButtonStyle. the remaining duplication appears to be the drawing and the paypal flow logic. analytics will be added in a follow-up PR.

[saralvasquez]

Ok cool! I think I was also wondering if there was a way to separate out the drawing methods since they are also really similar and then have both the PayPalButton and PayLaterButton both use the shared class for style and drawing? Do you think that would be a possibility? I just think it would make future changes a bit easier if it was all in one place

[agedd]

Ok cool! I think I was also wondering if there was a way to separate out the drawing methods since they are also really similar and then have both the PayPalButton and PayLaterButton both use the shared class for style and drawing? Do you think that would be a possibility? I just think it would make future changes a bit easier if it was all in one place

yes, great callout. i've pulled the drawing, sizing, spinner logic into an internal PaymentButtonRenderer that both PayPalButton and PayLaterButton now delegate to, so future style/drawing logic lives in one place.

[mzlangreder]

Are there scenarios where we might fail while still loading?

[saralvasquez]

Op. The AI just uncovered a bug in the payment buttons. If there is a failure that doesn't route through handleReturnToApp, like sending a bad request, the button gets stuck in the loading state since hideLoading is never called. Not something that necessarily need to be fixed in this PR since it's pre-existing, but I'll write up a ticket for it

[agedd]

Are there scenarios where we might fail while still loading?

ah yes, i think failures from createPaymentAuthRequest, a failed launch, and the null-activity case would have left the button disabled. added hideLoading(). each of those paths now calls hideLoading() before notifying the callback. i've also moved the re-enable in handleReturnToApp to after tokenize completes instead of when it starts.

[saralvasquez]

added hideLoading(). each of those paths now calls hideLoading() before notifying the callback

Great! Thank you! I'll update the bug ticket to only include the venmo button since this fixes the other two. Also, are there tests for these cases? I'm not sure I see any where we check to make sure the button is re-enabled after the failure cases

[saralvasquez]

I think with confirmation of the test cases I mentioned above this is ready to go. Great work!