Skip to content
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

Merged

Conversation

benjaminwil
Copy link
Contributor

@benjaminwil benjaminwil commented Mar 9, 2018

I have rewrote the payments/payment_processing.md article and removed/moved some of the content from it.

  • The new article goes more into detail about the authorize! and purchase! methods used for payment processing.
  • It moves information about payment states (on Spree::Orders) to a new article in the future orders/ section of the documentation.
  • It removes information about logging. Later, I will reintroduce documetation about logging in a new section.
  • I made more linear descriptions of what is involved in Solidus's processing process.

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.

in the future.
-->

You can check the state of the `Spree::Payment` associated with any order:
Copy link
Member

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.

Copy link
Contributor Author

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.

@benjaminwil benjaminwil force-pushed the payment_processing_documentation branch from 53f77c4 to 2d17116 Compare April 18, 2018 01:43
@benjaminwil benjaminwil changed the title Rewrite payment processing documentation Rewrite payment processing documentation; add Spree::Order#payment_states documentation Apr 18, 2018
- `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.
Copy link
Member

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

## Completed payments

The `Spree::Order`'s `payment_state` can only be `paid` if each `Spree::Payment`
has a state of `completed`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not true.

Copy link
Contributor

@DanielePalombo DanielePalombo left a 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.


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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

@DanielePalombo DanielePalombo Apr 20, 2018

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

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
returns an instance of this payment method. Gateway_options is the variable provided to the gateway class.

Copy link
Contributor Author

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.

@benjaminwil benjaminwil force-pushed the payment_processing_documentation branch from 3132a7d to a15066b Compare April 20, 2018 20:46
benjaminwil and others added 9 commits April 20, 2018 14:33
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.
@benjaminwil benjaminwil force-pushed the payment_processing_documentation branch from a15066b to 58cce89 Compare April 20, 2018 21:33
@gmacdougall gmacdougall merged commit c518327 into solidusio:master Apr 25, 2018
@benjaminwil benjaminwil deleted the payment_processing_documentation branch April 30, 2018 18:28
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.

4 participants