On Thu, Feb 9, 2017 at 7:45 AM, Cédric Krier <[email protected]> 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: [email protected] > 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. > -- 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/CAJ0%2BmOoCKmgQYh7gpCiketiVY%2BbTDDts1rvsPefotta4wZdj9Q%40mail.gmail.com.
