Using account_payment with invoices

[Mark Shane Hayden]

Hi everyone,

Some background:

I am investigating the use of the account_payment module for the purposes of integrating e-commerce on-line payments (as suggested by discussions on the topic of integrating Stripe, but I am looking to add support for services that are used frequently in Canada--notably Moneris and Beanstream).  The strategy is to interface with their payment gateways on the client side so communication with payment processing happens directly between the client's browser and the PCI compliant interfaces of the providers. Upon completion the browser submits the results returned from the payment provider (sanitised data like the token, result code, etc) to our server for Tryton to process.

We already have a web shop developed to the point where sales and invoices are created and now we are working on payment processing.  As suggested here:

https://discuss.tryton.org/t/minimal-e-shop-for-tryton/217

I am going to try using account_payment for this processing.  I have got it to the point where I can create and process a payment against the AR move line of a posted invoice but now I am stuck:

1. As mentioned in the above link and confirmed by my experimenting, payments do not perform any account moves, so from an accounting perspective it still shows the invoice as being unpaid and an outstanding balance in receivables.  HOWEVER, when I go to "pay" the invoice it shows an amount to pay of ZERO.  I cannot pay any amount on the invoice because it is more than the amount to pay.  I cannot leave the amount at zero because it does nothing and leaves the invoice in "posted" state.

2. If I go to the invoice and hit "pay" first, the receivables move in question is reconciled and I can no longer create a payment against that line.

So my question is what is the correct process to create payments against the AR move line associated with an invoice? Is this a bug or am I missing a step, or is it not possible using the "manual" processing method via the Tryton client and I have to make a module/code that does overrides the invoices' "pay" method?

I think I know how I could do the last thing, but I want to make sure I do the most "correct" thing.

PS. I would be interested in helping out with the payment integration solution for a minimal e-shop as discussed above.  Has any coding started on it, or blueprints/planning/etc?  I would like to make sure I don't create a one-off design for my "account_payment_beanstream" or "account_payment_moneris" modules if the one for stripe is already underway, and if it hasn't started I could contribute my efforts as a template.

Thanks,

Mark.

[Cédric Krier]

On 2017-02-08 18:48, Mark Shane Hayden wrote:
> Hi everyone,
>
> Some background:
>
> I am investigating the use of the account_payment module for the purposes
> of integrating e-commerce on-line payments (as suggested by discussions on
> the topic of integrating Stripe, but I am looking to add support for
> services that are used frequently in Canada--notably Moneris and
> Beanstream).

Do not know them but Stripe was chosen for its simple but secure API.

> The strategy is to interface with their payment gateways on
> the client side so communication with payment processing happens directly
> between the client's browser and the PCI compliant interfaces of the
> providers. Upon completion the browser submits the results returned from
> the payment provider (sanitised data like the token, result code, etc) to
> our server for Tryton to process.

It looks similar to the Stripe workflow.

> We already have a web shop developed to the point where sales and invoices
> are created and now we are working on payment processing. As suggested
> here:
>
> https://discuss.tryton.org/t/minimal-e-shop-for-tryton/217
>
> I am going to try using account_payment for this processing. I have got it
> to the point where I can create and process a payment against the AR move
> line of a posted invoice

It looks like you have implemented
https://discuss.tryton.org/t/sale-payment-before-validation/230
It will be great to submit it for inclusion.

> but now I am stuck:
>
> 1. As mentioned in the above link and confirmed by my experimenting,
> payments do not perform any account moves, so from an accounting
> perspective it still shows the invoice as being unpaid and an outstanding
> balance in receivables. HOWEVER, when I go to "pay" the invoice it shows
> an amount to pay of ZERO. I cannot pay any amount on the invoice because
> it is more than the amount to pay. I cannot leave the amount at zero
> because it does nothing and leaves the invoice in "posted" state.

This is the expected behavior. The invoice will be paid when you will
enter your bank statement which contains the payment.
Otherwise if you want to have clearing done earlier, you must use the
account_payment_clearing module which will move the paid amount on a
clearing account until you receive the statement.

> PS. I would be interested in helping out with the payment integration
> solution for a minimal e-shop as discussed above. Has any coding started
> on it, or blueprints/planning/etc? I would like to make sure I don't
> create a one-off design for my "account_payment_beanstream" or
> "account_payment_moneris" modules if the one for stripe is already
> underway, and if it hasn't started I could contribute my efforts as a
> template.

I have published our implementation of the Stripe payment at
https://bugs.tryton.org/issue6259

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[Raimon Esteve]

Hello,

At the moment we do esale payments with "account payment gateway". At the moment Redsys and Payal that use IPN to register payment.

All those modules could you find in our bitbucket account. Also in Twitter, searching with #galatea and #tryton could find some esale screenshots.

Regards

[Cédric Krier]

On 2017-02-09 22:43, Raimon Esteve wrote:
> Hello,
>
> At the moment we do esale payments with "account payment gateway". At the
> moment Redsys and Payal that use IPN to register payment.

I can not find what you are talking about.

> All those modules could you find in our bitbucket account.

What bitbucket account are you talking about?

> Also in Twitter,
> searching with #galatea and #tryton could find some esale screenshots.

Is it not better to post links ?

[Mark Shane Hayden]

On Fri, Feb 10, 2017 at 3:57 AM, Cédric Krier <cedric...@b2ck.com> wrote:

On 2017-02-09 22:43, Raimon Esteve wrote:
> Hello,
>
> At the moment we do esale payments with "account payment gateway". At the
> moment Redsys and Payal that use IPN to register payment.

I can not find what you are talking about.

I was a bit confused too because it wasn't in the modules repository of Tryton, but it is a module contributed by Raimon and not officially within the Tryton project.

 

> All those modules could you find in our bitbucket account.

What bitbucket account are you talking about?

I found it with a bit of googling when I was chasing down the whereabouts of the account_payment_gateway module::

https://bitbucket.org/zikzakmedia/profile/repositories

Within that there is the module and other very interesting stuff :)

https://bitbucket.org/zikzakmedia/trytond-account_payment_gateway

 

> Also in Twitter,
> searching with #galatea and #tryton could find some esale screenshots.

Is it not better to post links ?

Since I am not an active twitter user at the moment I haven't looked there yet. but searching the above bitbucket repo for galatea proved to be useful.  Thanks!

 

 

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

--
You received this message because you are subscribed to the Google Groups "tryton" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/20170210105702.GI83011%40tetsuo.

[Mark Shane Hayden]

On Thu, Feb 9, 2017 at 7:45 AM, Cédric Krier <cedric...@b2ck.com> wrote:

On 2017-02-08 18:48, Mark Shane Hayden wrote:
> Hi everyone,
>
> Some background:
>
> I am investigating the use of the account_payment module for the purposes
> of integrating e-commerce on-line payments (as suggested by discussions on
> the topic of integrating Stripe, but I am looking to add support for
> services that are used frequently in Canada--notably Moneris and
> Beanstream).

Do not know them but Stripe was chosen for its simple but secure API.

 

They seem to be the ones mentioned most by potential local customers is all. Beanstream is the premier payment processing provider for Toronto Dominion bank and Moneris is a joint venture between Royal Bank of Canada and Bank of Montreal.  Moneris is the largest provider of payment services and POS systems in Canada, while Beanstream is the lowest cost nationwide provider in Canada.

 

> The strategy is to interface with their payment gateways on
> the client side so communication with payment processing happens directly
> between the client's browser and the PCI compliant interfaces of the
> providers. Upon completion the browser submits the results returned from
> the payment provider (sanitised data like the token, result code, etc) to
> our server for Tryton to process.

It looks similar to the Stripe workflow.

> We already have a web shop developed to the point where sales and invoices
> are created and now we are working on payment processing.  As suggested
> here:
>
> https://discuss.tryton.org/t/minimal-e-shop-for-tryton/217
>
> I am going to try using account_payment for this processing.  I have got it
> to the point where I can create and process a payment against the AR move
> line of a posted invoice

It looks like you have implemented
https://discuss.tryton.org/t/sale-payment-before-validation/230
It will be great to submit it for inclusion.

 

I have partially implemented it yes, though in a different (probably more cumbersome) way. Plus I have to enforce some rules as described in that discussion. It so happens the sales created by our e-shop meet the criteria by default so I haven't encountered any problems so far.(invoicing is done "on order processed" and no payment term specified).  I did not think of using an "origin" rather than direct relations to the sales, so I think I will try that out before I put it out there for review.

My implementation is as a separate module at the moment (sale_payment). Should any or all of this be make into a patch for the account_payment module instead?  If a new module is better is the name sensible (vs. account_payment_sale or something like that)?

> but now I am stuck:
>
> 1. As mentioned in the above link and confirmed by my experimenting,
> payments do not perform any account moves, so from an accounting
> perspective it still shows the invoice as being unpaid and an outstanding
> balance in receivables.  HOWEVER, when I go to "pay" the invoice it shows
> an amount to pay of ZERO.  I cannot pay any amount on the invoice because
> it is more than the amount to pay.  I cannot leave the amount at zero
> because it does nothing and leaves the invoice in "posted" state.

This is the expected behavior. The invoice will be paid when you will
enter your bank statement which contains the payment.
Otherwise if you want to have clearing done earlier, you must use the
account_payment_clearing module which will move the paid amount on a
clearing account until you receive the statement.

 

I think the account_payment_clearing module is what I am after, thanks. Probably makes it easier to manage when reconciling merchant account statements.

 

> PS. I would be interested in helping out with the payment integration
> solution for a minimal e-shop as discussed above.  Has any coding started
> on it, or blueprints/planning/etc?  I would like to make sure I don't
> create a one-off design for my "account_payment_beanstream" or
> "account_payment_moneris" modules if the one for stripe is already
> underway, and if it hasn't started I could contribute my efforts as a
> template.

I have published our implementation of the Stripe payment at
https://bugs.tryton.org/issue6259

Thanks, I am looking at what is done there and it could be very useful.  The terminology is a bit different (What Stripe calls a "customer" beanstream calls a "payment profile" and so on), but they do a lot of similar things.

 

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

--
You received this message because you are subscribed to the Google Groups "tryton" group.

To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/20170209144502.GG83011%40tetsuo.

[Cédric Krier]

On 2017-02-10 17:43, Mark Shane Hayden wrote:
> On Thu, Feb 9, 2017 at 7:45 AM, Cédric Krier <cedric...@b2ck.com> wrote:
> > It looks like you have implemented
> > https://discuss.tryton.org/t/sale-payment-before-validation/230
> > It will be great to submit it for inclusion.
> >
> >
> I have partially implemented it yes, though in a different (probably more
> cumbersome) way. Plus I have to enforce some rules as described in that
> discussion. It so happens the sales created by our e-shop meet the criteria
> by default so I haven't encountered any problems so far.(invoicing is done
> "on order processed" and no payment term specified). I did not think of
> using an "origin" rather than direct relations to the sales, so I think I
> will try that out before I put it out there for review.
>
> My implementation is as a separate module at the moment (sale_payment).
> Should any or all of this be make into a patch for the account_payment
> module instead? If a new module is better is the name sensible (vs.
> account_payment_sale or something like that)?

I think it should be named: sale_payment