Skip to content

Conversation

@SamNie2027
Copy link
Contributor

@SamNie2027 SamNie2027 commented Oct 20, 2025

Description

Initial Stripe configuration and Stripe service implementation.

Changes Made

  • Create apps/backend/src/payments/ directory
  • Create payments.module.ts with Stripe configuration / Stripe SDK configured
  • Create payments.service.ts with methods:
  • createPaymentIntent(amount, currency, metadata)
  • createSubscription(customerId, priceId, interval) - apparently interval data is actually already stored within the price
  • retrievePaymentIntent(paymentIntentId)
  • STRIPE_SECRET_KEY added to example.env
  • STRIPE_PUBLISHABLE_KEY added to example.env
  • All three methods unit tested with Stripe mock with parameter acceptance edge cases
  • PaymentsService can create test payment intents - test payment intents are created as long as you are working with Stripe test environment api keys
  • Environment variables + implementation is documentated
  • Tests pass with mocked Stripe client

Things mentioned in ticket that have not been implemented:

  • STRIPE_WEBHOOK_SECRET - we are still researching webhooks currently and weren't sure if it was actually necessary for this current iteration of payment service impl
  • Checking that the Stripe SDK integrates - we haven't tested with the Stripe API itself, only the mock

Testing & Verification

Unit tested with edge cases for parameter validation. Stripe mock returns realistic return objects and we validate how our code transforms that data to give flexible information to the user of these methods.

However, we have not tested integration with calling the real Stripe API, and have not tested in the Stripe test environment with using Stripe API keys in any way. Those are the next steps for this part of the project.

Future Improvements/Notes

PaymentIntentResponse and Create Subscription return object shapes are subject to change based on what is best needed for the frontend. PaymentIntentResponse is a larger object that enables more flexibility, while the Create Subscription return shape could be modified if there is more information needed.

While we return client secrets, we have not yet researched what these are used for. Only we know that these are usually used in modern Stripe implementations.

Testing in the Stripe test environment is necessary to ensure reliability and security. On the same note, not much security hardening has been done with this initial implementation so that is also a necessary next step.

Related Issues

Closes #16 Payment Integration Setup (Stripe)

Note:
- USD is given in us cents
- 50 cent minimum according to Stripe, we can reject here instead of letting that go to Stripe
- Payment method types: card (debit or credit) and us bank accounts, covers most use cases
- Payment method types could be more expansive (we could switch Stripe to self-determine accepted method types based on user characteristics) but it may not be worth it because it could require more frontend work for very rare edge cases.
…atch current invalid param checks for createPaymentIntent
…t will throw if Stripe API throws, also more realistic Stripe Success returns
@SamNie2027 SamNie2027 linked an issue Oct 20, 2025 that may be closed by this pull request
@thaninbew
Copy link
Collaborator

Made very minor changes, let me know if it's all good to merge!

@SamNie2027
Copy link
Contributor Author

Yes looks good, thank you for reviewing!

@thaninbew thaninbew merged commit 7eed1be into main Oct 27, 2025
4 checks passed
@thaninbew thaninbew deleted the 16-Payment-Integration-Setup-Stripe branch October 27, 2025 22:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Payment Integration Setup (Stripe) (Pair programming)

4 participants