MVP implementation that can complete a checkout#156
Conversation
028c385 to
0da82df
Compare
0da82df to
4a69d77
Compare
Follow the same style we already have for the dummy-app script.
This is only useful for development. It runs again the installer whenever one of the relevant sources changes, and only runs the parts of the installers necessary for an update, which is faster than running everything.
5a83713 to
8c07acf
Compare
b95c06e to
6813058
Compare
- publishable_key - partial names - factory with spec
6813058 to
92cc121
Compare
92cc121 to
a8bf830
Compare
kennyadsl
left a comment
There was a problem hiding this comment.
Thank @elia, this is a great start. I left just some questions/comments.
Also, now that we are fresh with some concept, I think this might be a good moment to add some YARD documentation to the main gateway/payment method methods that could help us in the future. Do you think this might have some value?
|
|
||
| module SolidusStripe | ||
| class PaymentSource < ::Spree::PaymentSource | ||
| def gateway_payment_profile_id=(value) |
There was a problem hiding this comment.
Thoughts on using https://apidock.com/rails/Module/alias_attribute?
| end | ||
|
|
||
| # To create a requires_capture PaymentIntent, | ||
| # see our guide at: https://stripe.com/docs/payments/capture-later |
There was a problem hiding this comment.
Is our referring to Stripe here? Maybe we can be more explicit about it.
| Set `SOLIDUS_STRIPE_API_KEY` and `SOLIDUS_STRIPE_PUBLISHABLE_KEY` environment variables (e.g. via `direnv`), this | ||
| will trigger the default initializer to create a static preference for SolidusStripe. | ||
|
|
||
| Run `bin/dev` to start both the sandbox rail server and the file watcher that will update the sandbox whenever |
There was a problem hiding this comment.
What if bin/dev also creates the payment method if needed? I think it would be a great UX improvement but don't know if that's easy to do. Thoughts?
There was a problem hiding this comment.
Added the static pref that for some reason was left out of the PR and bin/sandbox will auto-create the payment method connecting to the static pref if the same env var is present. 👍
| end | ||
|
|
||
| def create_profile(payment) | ||
| pi = payment.source.payment_intent |
There was a problem hiding this comment.
I'd prefer to avoid 2-letter variables. payment_intent is not that long that will create problems IMHO, thoughts?
|
|
||
| require 'solidus_stripe_spec_helper' | ||
|
|
||
| RSpec.describe SolidusStripe::PaymentIntentsController, type: :request do |
There was a problem hiding this comment.
If I'm not mistaken here, the best practice is to avoid adding the _controller part to the filename and to the main describe name. In general, the file seems too tied to the controller, while requests specs should be more of a full request-cycle spec.
There was a problem hiding this comment.
I just checked the RSpec generator as I wasn't sure about what changes I added, this is how it looks like:
require 'rails_helper'
RSpec.describe "<%= class_name.pluralize %>", <%= type_metatag(:request) %> do
describe "GET /<%= name.underscore.pluralize %>" do
it "works! (now write some real specs)" do
get <%= index_helper %>_path
expect(response).to have_http_status(200)
end
end
endSo the only thing I changed was removing the quotes from around the class name so I could use described_class, happy to change it if there's a different/better way.
There was a problem hiding this comment.
Yes, but I think that the class should not be a controller in the request specs. Looking around for examples it seems like it's a more high level concept that a specific class.
| > | ||
| <div data-solidus-stripe-payment-target="paymentElement"> | ||
| <!-- Elements will create form elements here --> | ||
| <em>Loading...</em> |
| <dt><%= SolidusStripe::PaymentSource.human_attribute_name(:stripe_payment_intent_id) %>:</dt> | ||
| <dd><%= link_to( | ||
| payment.source.stripe_payment_intent_id, | ||
| "https://dashboard.stripe.com/#{'test/' if payment.payment_method.preferred_test_mode}payments/#{payment.source.stripe_payment_intent_id}", |
There was a problem hiding this comment.
Thought about moving this URL generation to the payment source model?
It's shorter (and works better with my editor, but please don't tell anyone! :P).
It will be used by the frontend code to generate a client-secret. In order for the routes to be defined on SolidusStripe we need to isolate the namespace on the extension itself.
Only the happy path is taken into account, support for saving profiles and wallet is yet to be added.
This will allow capturing, voiding, and canceling stripe payments.
Make auto create a payment method in development if the same env var is available.
a8bf830 to
d6a7c23
Compare
|
@elia I think you missed the YARD documentation part of my review comment, I can't find any reply to that and nothing changed in the code proposed. 👓 |
Thanks for calling that out, I indeed missed the comment. It's probably early for adding documentation but I did it anyway mostly to have an idea of what it looks like, many gateway methods are still incomplete and will change considerably, but the current situation should be covered accurately. |
kennyadsl
left a comment
There was a problem hiding this comment.
Thanks Elia, I'm sure that even if it's going to change, this Yard documentation won't be regretted.
Summary
Aiming at the simplest implementation that allows completing a checkout.
The mapping between Stripe and Solidus models won't be final and subject to deep changes.
We don't expect anyone grabbing this extension from master given the big warning against that that we have at the top of the readme.
Fixes #152
Checklist
Check out our PR guidelines for more details.
The following are mandatory for all PRs:
The following are not always needed (
cross them outif they are not):