-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rewrite payment processing documentation; add Spree::Order#payment_states documentation #2624
Rewrite payment processing documentation; add Spree::Order#payment_states documentation #2624
Conversation
in the future. | ||
--> | ||
|
||
You can check the state of the `Spree::Payment` associated with any order: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are two ways that the state of payments are represented. There is the state of the payment status for the order, which is what is described below and the state of an individual payment.
As an example:
An order for $100 has a single payment of $50 that is complete. The status of the one payment is complete, but the order is in a payment state of balance_due.
If the order has multiple payments:
- $80 - failed
- $80 - completed
- $80 - completed
The order will be in a payment_state of credit owed.
Refunds play in to this as well as those can bring the payment state back in to a state of pair if the customer overpaid in the above case. This is complicated enough that it needs an explanation of what the difference between order payment_state
and payment's state
is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am going to include an example like this, thank you.
53f77c4
to
2d17116
Compare
guides/orders/payment-states.md
Outdated
- `credit_owed`: This state indicates that the order has been paid for in excess | ||
of its total. | ||
- `paid`: This state indicates that the order has been paid for in full. All of | ||
the `Spree::Payment`s on the order have been satisfied. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An order can also be in the state void
guides/orders/payment-states.md
Outdated
## Completed payments | ||
|
||
The `Spree::Order`'s `payment_state` can only be `paid` if each `Spree::Payment` | ||
has a state of `completed`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not true.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work. I leave a comment about the Spree::PaymentMethod#gateway.
guides/orders/payment-states.md
Outdated
|
||
The `payment_state` method can be very useful if you have built out your own | ||
integrations with a payment service provider. For example, a sudden increase in | ||
orders with with `payment_state` of `failed` may indicate a problem with your |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
with
is repeated two times
`purchase!` is called, meaning the payment is authorized and captured. This | ||
occurs even if the payment's state is already `completed`. | ||
- If the `Spree::PaymentMethod`'s `auto_capture` attribute is set to `false`, | ||
then the payment is authorized but not captured. This occurs even if if the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if
repeted twice
|
||
- `Spree::PaymentMethod` has a similar interface to API provided by | ||
[active_merchant][active-merchant]. | ||
- The `Spree::PaymentMethod#gateway` method uses the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I'm wrong, but seems like gateway
method
solidus/core/app/models/spree/payment_method.rb
Lines 130 to 137 in f2a921e
def gateway | |
gateway_options = options | |
gateway_options.delete :login if gateway_options.key?(:login) && gateway_options[:login].nil? | |
if gateway_options[:server] | |
ActiveMerchant::Billing::Base.mode = gateway_options[:server].to_sym | |
end | |
@gateway ||= gateway_class.new(gateway_options) | |
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for making a note of this. While the options
value is created by the Spree::Payment::Processing#gateway_options
the way that I wrote this didn't really make sense.
I'm going to simplify it shortly and leave explanations to the "Gateway options" section below.
3132a7d
to
a15066b
Compare
Currently, the payment_processing.md article has a list of payment states. While it is useful in that context, this is related more to orders than to payments. I'm stripping it out of the article and putting it in the orders section of documentation as a new stub article.
- Add `void` to list of order payment states - Create better explanations and examples for payment states in the docs.
a15066b
to
58cce89
Compare
I have rewrote the
payments/payment_processing.md
article and removed/moved some of the content from it.authorize!
andpurchase!
methods used for payment processing.Spree::Order
s) to a new article in the futureorders/
section of the documentation.This is a pretty dense article. Payment processing is confusing. In the future, I'd like to take this article in a more tutorialized direction set up a payment method that uses a real payment service provider like Stripe.
This is part a larger project to improve Solidus's documentation. See this gist with the high-level table of contents. Where and how this documentation will exist is still up for discussion.