is there a pay-upfront payment processor in GetPaid ?

[MikeZ]

Hi,

I think i have asked this on plone-users before but couldn't find it
anymore so i'll ask again here:
Will there be a payment processor on board to deal with shops that
only go for pay-first-by-bank-then-ship-order systems?

In the Netherlands the low-volume shops only use this basically.
Their next step-up would be the IDEAL system, which is not that easy
btw., but is supported by all Dutch banks.
Paypal is rarely used and Google Checkout even less (i think).
i have seen some payment-processors listed at the wiki which i haven't
even heard of ...

rgrds Mike

[MikeZ]

Hi,

rgrds Mike

(i'm posting this again since first is sort-of-deleted)

[Christopher Johnson]

Hi Mike,

I assume you are referring to a situation where someone is committing to pay on their checkout by a means not via the site. So the order is marked as pending payment (via that means), and then the site admin would have to update its status once payment was received (to begin fulfillment).

Is that what you are referring to? If not, please provide greater information about how this works, as I am not familiar with it.

Cheers,
Chris

--
Cofounder and CEO
ifPeople - Innovation for People
www.ifpeople.net
t: 678-608-3408
130 Boulevard NE, #6
Atlanta, GA 30312

[MikeZ]

yep,
exactly.
GetPaid would only be used for the shopping-cart experience, not the
payment itself.
It provides a system for the buyer to do structured shopping with a
cart and a totalising screen, email confirmation etc.
It would provide the shopowner with an interface to see the orders,
pending or paid, and ofcourse email notification when the order was
processed etc.
Payment would indeed be manual and the shopowner would be the one to
check if he got the payment before marking the order payed, and being
shipped therefore.

rgrds Mike

On Sep 21, 7:34 pm, "Christopher Johnson" <cjj.ifpeo...@gmail.com>
wrote:

> Hi Mike,
>
> I assume you are referring to a situation where someone is committing to pay
> on their checkout by a means not via the site. So the order is marked as
> pending payment (via that means), and then the site admin would have to
> update its status once payment was received (to begin fulfillment).
>
> Is that what you are referring to? If not, please provide greater
> information about how this works, as I am not familiar with it.
>
> Cheers,
> Chris
>

[Christopher Johnson]

Mike - this situation is totally possible with GetPaid. To get it working, you will want to tweak the workflow associated with this payment option. You should also probably add this as a "payment option" for the admin screen.

Have a look around the code to see how it is currently working. Until recently (ie last week), the orders actually weren't processed right away, so looking at the slightly older code you can see how the order financial and fulfillment process was (vs is now).

If you need commit rights to the project (to make a branch or commit changes), please let me know off the list.

Cheers,
Chris

[Kapil Thangavelu]

following up on chris's comments.

orders are subject to 2 parallel and interdependent workflows, finance
and fulfillment.

the default configuration is in getpaid.core.workflow.configure.zcml

in your own product, you can override the default workflow with one of
your choosing, that will apply a different finance workflow.

thinking about it, i think the current payment processor integration
with workflow needs some tweaking to force adapation to workflow as
well within the subscriber. its currently does all the work inside an
event subscriber for order workflow, which makes it hard to override
the default policy, since subscribers aren't overrideable their only
addable.

cheers,

kapil

--
Vision Implemented - http://objectrealms.net

[Kapil Thangavelu]

i went ahead and tweak the workflow so the processor integration uses adapation.

so basically to implement your use case.

i'll assume you have a custom product lying around.

you would create another a finance workflow (using hurry.workflow),
basically three states, pending, reviewing, paid. with a tranasition
from pending to reviewing of authorizing, and transition from
reviewing to paid specified as type manual user transition, don't
subclass from the default finance one, as you'll inherit some of its
configuration. you would register your new workflow in your product's
overrides.zcml as the finance workflow for an order, using
getpaid.core.workflow.configure.zcml as an example. of doing so. you
can then use a hookup a dummy payment processor (available by default)
in the store configuration ui.

so now in the order management screens after someone submits an order
it will show up as in state reviewing, and will require an admin to
click on the transition to set the state as paid.

hth,

kapil