| View Cart (0)
| Previous · Next | |
| User | Message |
|
arjan
|
Date: 2/20/2008 12:20 pm · Subject: Ogone Payment Plugin · Rating: 7
Hi all,Together with Procolix (Koen) I would like to develop a payment plugin. I would like to have it distributed with the standard release. My aim here is to a) discover what requirements should be met for this - or any - plugin and b) whether our requirements are compatible with the new commerce system and perhaps this case sharpens the specification. Contents 1. Our demands to the functionality 1.1 some demands that may have nothing to do with the plugin, but may with the commerce system 1.2 the payment service provider (PSP) we would like to have support for 2. The demands the WebGUI community puts to such a plugin that I know off 3. The questions about the specification this combination of demands brings about Demands to the functionality Our main demand is to have the ability to have recurring payments. This can be done with most credit cards and in Holland with something called "Machtigingen" (literally translated: authorizations). We would like to be able to sell something abroad. In Holland most export is tax-free. This is may be a demand to the commerce system itself. (and it may not be, see below) We would like to use Ogone as PSP and make a plugin for their standard e-commerce solution. (and make WebGUI a 'connector' in the process) I think the best way to go is to use their option to hand off the process to Ogone from the moment someone indicates he wishes to pay. This probably is a demand to the commerce system itself. (see also below) I will elaborate on the demands later, after I've studied the details of the Ogone payment gateway. The demands I know off These are always true: 1. build tests (which tests exactly should become clear later in the discussion) 2. internationalization 3. templatability of all views (which I have learned to specify: selectable templates such as most of WebGUI's templates are) 4. follow the WebGUI best practices (all of the Rules that Damian Conway describes?) 5. use the Class::InsideOut But what demands should be met by a commerce plugin specifically, if any, to be included? Should this be an arbitrary selection? I would guess that perhaps somebody should be committed to maintain them? The issues The first two questions are related to 2) and 3) of the Must Haves: "2. There must be a callback system after checkout." "3. There's currently no way to apss off the checkout process to a third-party web site such as PayPal, ..." 1. Some PSP's expect to take over the process from the selection of billing options. If you have just one payment gateway defined, the most elegant thing would be to directly direct this user to the PSP I guess. In this way the 'display billing options' would be at the PSP's site. 2. How are recurring payments handled? I would guess there are cases in which - the customer selects this option at the PSP and the PSP confirms at merchant somehow of the next payment without customer involvement - the merchant sets option via the payment plugin at PSP and the PSP confirms at merchant somehow of the next payment without customer involvement - the merchant triggers the next payment at PSP? And if you allow customers to pay once for a subscription-like product: - the merchant sends an email with a link to the merchants website, where the product has already been put in his/another cart - the merchant sends an email with a link to the PSP's website? 3. PSP's most often offer many different options, billing methods to use or not, etc. Should such options be a part of the plugin, so they are configurable via the WebGUI interface or would it be best if they were configured elsewhere? 4. In the specification the payment gateway has a create method with a hash reference with the parameters in the coupon table. Is this intended for giving a discount on the basis of the chosen billing option? I will look more deeply into the technical specs of Ogone to answer part of these questions myself. Some other things 1. In many countries you don't have to pay VAT for *some* products if you export them to (most?) countries and the are produced or delivered in the country of origin. Whether or not VAT has to be payed is determined by the country of the customer in relation to the country of the shop. I don't know if - in the case of Ogone - this is perhaps handled by the PSP, but I will look into this. But if this is handled by the PSP this probably creates more problems than are solved. So I guess would be best if the commerce system can determine this. Some small things I noticed 1. In the 'user experience' diagram of the shopping cart and check out process, there is no arrow between "Log in or create account" and "Display billing options". It would be elegant if the users which to checkout is remembered and he is directed to the display of the billing options or to the only payment gateway that is available after login or create account in this case. 2. Shipping, should shipping/no-shipping be a property of all products in the sense that shipping is completely hidden if all products in the cart don't require shipping? Or should shipping always be visible in a cart and you use the flat rate shipper with a rate of zero? 3. In the flat rate shipper module there is the calculate formula. It says that the total price is multiplied with a percentageOfPrice. Is that what you intend? A percentage off is always on a total, not on a product? Suggestions 1. Perhaps we could add to 'Pipe dream': upgrades. Many products are only interesting if the customer has already bought something else. Think: Dell's 3 years extra service, or upgrade you WebGUI hosting account. And P.s. what is a subscription recurring url? Kind regards, Arjan Widlak Visit us: http://www.unitedknowledge.nl United Knowledge, inhoud en techniek Keizersgracht 74 1015 CT Amsterdam T +31 (0)20 52 18 300 F +31 (0)20 52 18 301 http://www.unitedknowledge.nl |
| Back to Top |
Rate [ | ]
|
|
JT
|
Date: 2/20/2008 1:25 pm · Subject: Re: Ogone Payment Plugin · Rating: -12
> Together with Procolix (Koen) I would like to develop a payment > plugin. > I would like to have it distributed with the standard release. My aim > here is to > a) discover what requirements should be met for this - or any - plugin > and > b) whether our requirements are compatible with the new commerce > system > and perhaps this case sharpens the specification. Great. > Demands to the functionality > Our main demand is to have the ability to have recurring payments. > This > can be done with most credit cards and in Holland with something > called > "Machtigingen" (literally translated: authorizations). Whether you can do recurring payments with this provider connected to our commerce system is really up to how they handle recurring payments. If they support recurring payments, then I would say you have an 90% chance that it will work with our commerce system. I've only seen one that I would not allow so far because it required storing the credit card number on the webgui server, which is just a security nightmare waiting to happen. > We would like to be able to sell something abroad. In Holland most > export is tax-free. This is may be a demand to the commerce system > itself. (and it may not be, see below) Tax free is the default in the commerce system. Unless you specify a tax rate for a country it charges no tax. So this is already handled. > We would like to use Ogone as PSP and make a plugin for their standard > e-commerce solution. (and make WebGUI a 'connector' in the process) I > think the best way to go is to use their option to hand off the > process > to Ogone from the moment someone indicates he wishes to pay. This > probably is a demand to the commerce system itself. (see also below) > I will elaborate on the demands later, after I've studied the > details of > the Ogone payment gateway. So Ogone is like paypal in which it's a web interface handshake rather than a background payment system? Either way the new commerce system is set up to handle this. That was one of the key things I didn't like about the old one. > The demands I know off > These are always true: > 1. build tests (which tests exactly should become clear later in the > discussion) > 2. internationalization > 3. templatability of all views (which I have learned to specify: > selectable templates such as most of WebGUI's templates are) > 4. follow the WebGUI best practices (all of the Rules that Damian > Conway > describes?) > 5. use the Class::InsideOut Yup on all counts. > But what demands should be met by a commerce plugin specifically, if > any, to be included? Should this be an arbitrary selection? I would > guess that perhaps somebody should be committed to maintain them? The big one is that the payment gateway has to work out of the box without installing any additional drivers or other such nonsense (it should be a web services or other http interface). The only one I know that requires this BS is PayFlowPro (aka CyberCash), so that shouldn't be a problem. If your payment gateway requires these drivers then it cannot be shipped as a standard component with WebGUI. The other thing is that I don't want Plain Black to get stuck with maintaining a thousand different payment gateway adapters. Our goal is to choose a few of the most popular (one or two direct credit card processors, paypal, google checkout, and maybe 2checkout.com). But below you've offered to maintain it so that isn't a problem. > The issues > The first two questions are related to 2) and 3) of the Must Haves: > "2. There must be a callback system after checkout." The callback has nothing to do with the payment gateway. This is just a natural function of the commerce transaction subsystem. > > "3. There's currently no way to apss off the checkout process to a > third-party web site such as PayPal, ..." The new system cures this. > 1. Some PSP's expect to take over the process from the selection of > billing options. If you have just one payment gateway defined, the > most > elegant thing would be to directly direct this user to the PSP I > guess. > In this way the 'display billing options' would be at the PSP's site. Not necessarily. Because you might have both google checkout and paypal defined as payment gateways on your WebGUI site. So you have buttons for each of those, which then redirect you to the appropriate PSP. > 2. How are recurring payments handled? I would guess there are cases > in > which > - the customer selects this option at the PSP and the PSP confirms at > merchant somehow of the next payment without customer involvement > - the merchant sets option via the payment plugin at PSP and the PSP > confirms at merchant somehow of the next payment without customer > involvement > - the merchant triggers the next payment at PSP? > And if you allow customers to pay once for a subscription-like > product: > - the merchant sends an email with a link to the merchants website, > where the product has already been put in his/another cart > - the merchant sends an email with a link to the PSP's website? This depends entirely on your PSP. But for most of them what happens is the PSP triggers the next payment, and then calls a URL on your WebGUI site that triggers the next transaction. > 3. PSP's most often offer many different options, billing methods to > use > or not, etc. Should such options be a part of the plugin, so they are > configurable via the WebGUI interface or would it be best if they were > configured elsewhere? This again depends upon the PSP. The new commerce system doesn't force any particular requirements upon you so you can do whatever the the PSP gives you access to do. However, my requirement is that you take the payment gateway as far as is possible with the APIs that are provided. By making as much configurable in WebGUI you make it easier for the end user. They don't have to go deal with someone else's interface. > 4. In the specification the payment gateway has a create method with a > hash reference with the parameters in the coupon table. Is this > intended > for giving a discount on the basis of the chosen billing option? That's a typo. The most recent version of the specification for payment gateways removes that. > I will look more deeply into the technical specs of Ogone to answer > part > of these questions myself. Great. > > Some other things > 1. In many countries you don't have to pay VAT for *some* products if > you export them to (most?) countries and the are produced or delivered > in the country of origin. Whether or not VAT has to be payed is > determined by the country of the customer in relation to the country > of > the shop. I don't know if - in the case of Ogone - this is perhaps > handled by the PSP, but I will look into this. But if this is > handled by > the PSP this probably creates more problems than are solved. So I > guess > would be best if the commerce system can determine this. I think our tax system automatically handles this case. I recommend you read the tax spec in the updated docs and make sure that's the case. > Some small things I noticed > 1. In the 'user experience' diagram of the shopping cart and check out > process, there is no arrow between "Log in or create account" and > "Display billing options". It would be elegant if the users which to > checkout is remembered and he is directed to the display of the > billing > options or to the only payment gateway that is available after login > or > create account in this case. Despite the lack of an arrow, the plan all along is that the user be redirect to the right spot after login. I've fixed the image in subversion now. > 2. Shipping, should shipping/no-shipping be a property of all products > in the sense that shipping is completely hidden if all products in the > cart don't require shipping? Or should shipping always be visible in a > cart and you use the flat rate shipper with a rate of zero? isShippingRequired is a method on all Skus. And it will certainly be enabled in the Product asset, but some things like Subscriptions and Donations are never shippable. That's why there shouldn't always be a switch in the asset. > 3. In the flat rate shipper module there is the calculate formula. It > says that the total price is multiplied with a percentageOfPrice. Is > that what you intend? A percentage off is always on a total, not on a > product? Typo. I've fixed it in the shipping docs now. > Suggestions > 1. Perhaps we could add to 'Pipe dream': upgrades. Many products are > only interesting if the customer has already bought something else. > Think: Dell's 3 years extra service, or upgrade you WebGUI hosting > account. That would be an option on the product type I would think. Cuz it's a property of the product rather than a separate product itself, at least as far as our commerce system is concerned. > > And P.s. what is a subscription recurring url? It's an idea I'm toying with. Rather than have the payment gateway deal with recurring payment triggers, I'm thinking about having subscription and other recurring assets deal with their own. However, this is not set in stone, it's only a thought that is not entirely fleshed out yet. We'll deal with that as we get some of the commerce system completed and see what way will work best. JT Smith ph: 703-286-2525 x810 fx: 312-264-5382 Create like a god. Command like a king. Work like a slave. |
| Back to Top |
Rate [ | ]
|