Yesterday afternoon we made a new Alpha release of Pay for Drupal available. What is Pay you might ask? At its core Pay is a modular API for accepting, processing and tracking payments. If you want to be able to accept payments on your Drupal site for simple transactions with out "Add to cart" or complicated checkout procedures then Pay is for you! To learn more about Pay, take a look at our blog post last week and check out the project page.
As part of the Pay API we provide a set of base classes which can be extended to provide payment forms or payment methods and gateways. Out of the box we're currently shipping with support for Authorize.Net and PayFlowPro payment gateways. While at DrupalCon Copenhagen I began adding support for PayPal Website Payments Pro and Standard. While still under development some of this work is now available for testing in the latest alpha.
As we move forward with development we'd love to get your feedback. Whether you're a developer who's interested in extending Pay, a site implementer who'd like to add it to their toolbox or the maintainer of a Drupal site that could use some simple payment handling - we encourage you to download Pay and give it a try then get back to us. We're especially interested in talking to people about their use cases for simple payment handling.
Feel free to get in touch with us with your questions or comments either through the project page, or our contact form here at Advantage Labs.
Comments
One thing I've been trying
One thing I've been trying to nail for some time is payment in tandem with webform submissions. I'd like my webforms to have a checkbox that is invisible to the end user that says 'Paid', and when they submit the webform, they are then directed to PayPal (or someplace else) to submit payment. Once the payment completes, the webform's checkbox would be updated...
We'd very much like to implement that!
I think that the best way to handle such a thing is to implement a webform component that allows you to embed a payment form, such as an optional donation form or a simple payment form, onto any webform.
This type of thing is at the top of our wishlist, we just need someone who would benefit from the ROI of having us build it.
In the meantime, your description is different from how I would have envisioned it, so seeing your input will only make the end result better!
cart integration
I currently develop an ecommerce site using ubercart. The more I use it, the more I wish if it consists a collection of separate modules working together to handle things such as shopping cart, order processing and payment gateway rather one complete e-commerce package. This is because I don't use much of ubercart features other than just the cart, order and payment module. Lot of things in custom code to achieve what we need and at the same time have to work around ubercart's quirks.
So, is it possible for "Pay" to integrate with other solutions that implement the cart and order facility and together we have our own custom e-commerce solution but still reusing most the common parts ?
That's precisely the goal!
There are lots of reasons to accept payments on your site, and a shopp so complex, you forget it's not the only reason to accept payments. But ing cart is the "vocal minority" of your use cases: by complexity, managing a shopping cart system can be the largest part of your site. But by quantity, it's only one of many, many reasons to transfer money.
Other uses include tip jars, site membership subscriptions, donations, ticket sales, simple order forms, event registration, and lots more. In these types of transactions, a cart may be a useful option, but most of the time it's an obstruction.
It's our opinion that a single Payment API should be used for all transactions, including shopping carts. This would allow you to install something simple for, say, donations; and then decide later that you really want a full blown shopping cart for selling other things. If these systems were to share a Payment API, your payment method configuration, reporting, user preferences would be in the same spot as you added and removed functionality.
BHITVISyjQGHryzpGH
If you want to get read, this is how you sholud write.
I think that the best way to
I think that the best way to handle such a thing is to implement a webform component that allows you to embed a payment form, Hispanic Grants such as an optional donation form or a simple payment form, onto any webform.
There are lots of reasons to
There are lots of reasons to accept payments on your site, and a shopp so complex, you forget it's not the only reason to accept payments. wolff parkinson white But ing cart is the "vocal minority" of your use cases: by complexity, managing a shopping cart system can be the largest part of your site. But by quantity, it's only one of many, many reasons to transfer money.
It's our opinion that a
It's our opinion that a single Payment API should be used for all transactions, including shopping carts. This would allow you to install something simple for, say, donations; and then decide later that you really want a full blown shopping cart for selling other things. waterhouse friderichsen syndrome
If these systems were to share a Payment API, your payment method configuration, reporting, user preferences would be in the same spot as you added and removed functionality.
I currently develop an
I currently develop an ecommerce site using ubercart. The more I use it, the more I wish if it consists a collection of separate modules working together to handle things such as shopping cart, Prilosec order processing and payment gateway rather one complete e-commerce package. This is because I don't use much of ubercart features other than just the cart, order and payment module
Post new comment