GithubHelp home page GithubHelp logo

agiliq / merchant Goto Github PK

View Code? Open in Web Editor NEW
1.0K 1.0K 170.0 1.21 MB

A Django app to accept payments from various payment processors via Pluggable backends.

Home Page: http://agiliq.com/demo/merchant

License: BSD 3-Clause "New" or "Revised" License

Makefile 0.09% Python 94.92% HTML 4.99%

merchant's Introduction

Django-Merchant

TravisCI

Django-Merchant is a django application that enables you to use multiple payment processors from a single API.

Gateways

Following gateways are supported:

  • Authorize.net
  • Paypal
  • Eway
  • Braintree Payments (Server to Server)
  • Stripe
  • Paylane
  • WePay
  • Beanstream
  • Chargebee
  • Global Iris

Off-Site Processing

  • Paypal
  • RBS WorldPay
  • Amazon FPS
  • Braintree Payments (Transparent Redirect)
  • Stripe.js
  • eWAY
  • Authorize.net Direct Post Method
  • Global Iris RealMPI

Other

  • Bitcoin

Documentation

Documentation is automatically built and published online at:

http://readthedocs.org/docs/django-merchant/en/latest/

Support

There is a mailing list where discussion regarding the development and usage of merchant happens:

http://groups.google.com/group/django-merchant/

merchant's People

Contributors

aldarund avatar arjunchitturi avatar ashok-raavi avatar benvand avatar bradleyayers avatar dillongreen avatar dulacp avatar elimisteve avatar fengsi avatar fkoksal avatar fruitschen avatar hayyat avatar issackelly avatar kamotos avatar kencochrane avatar lalitchandnani avatar litchfield avatar llonchj avatar manjunath24 avatar mattmcc avatar mikery avatar nmonteiro avatar prggmr avatar shabda avatar spookylukey avatar theju avatar tomaratyn avatar tomchristie avatar tuxcanfly avatar tyc85 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

merchant's Issues

PayPal multiple item processing doesn't support most allowed fields

Currently, the PayPal standard form allows for submitting multiple items, but only supports the 'item_name_x' and 'amount_x' fields. There are in fact a whole host of other fields which PayPal accepts in their API.

I'm currently working up a patch to allow most, if not all of, these fields. I just wanted to add a ticket in here in order to attach a pull request.

Better document in Integration module.

Please write more document about the integration module.
And about the Integration module, function get_integration.

integration_class_name = "".join(integration_filename.title().split("_"))

actually We can't define the specific class module name for the class .

we can use

ggg = import_module("apps.xxx.xxxx")
ggg.__class__
ggg.__class__.__name__

to get the module class right. but the disadvantage we must give the specific name just like Integration for the class name postfix.

Hope you can fix this bugs .
If I have more free time , I will make the pull request.

Register models in admin based on settings supplied

In billing/admin.py
is there a reason that all those models are blanket registered with the admin?
Could this not be based on settings? Something like

for key in settings.MERCHANT_SETTINGS:
    admin.site.register(key_model_dict['key'])

NO notification of payment

After payment we need to get notifications.

I got a notification from Google-checkout but not the app.

SAQ-A level compliance for Authorize.NET (off-site card processing)

Authorize.NET supports a "Direct Post Method" for processing credit cards (similar to Braintree's "Transparent Redirect"). After attending DjangoCon and listening to Ken Cochrane's talk on PCI compliance, I think many people don't realize the risk they're putting clients through when they don't use SAQ level A implementations.

Do you know the effort involved in making an implementation of DPM on the authorize.net gateway module? If it's not a massive change, I'm happy to work on it and provide a pull request.

Needs better docs

We need better docs on

  1. How to integrate it with existing Djnago sites.
  2. Hoe to test things.

Harmonize module and package name

A lot of Django reusable apps use as package name django-<module_name>. Therefore I would expect django-merchant to contain a module called merchant. Right now it uses billing which drives me nuts for several reasons:

  • Upon installing django-merchant one expects a merchant or django_merchant module in the PYTHONPATH; surely not an app called billing.
  • Merchant is not about billing. Billing is the process of writing an invoice and sending it to the customer. Merchant does not know about invoices and is in fact just a generic API to payment providers. Quoting Wikipedia: "Billing may refer to: The process of sending an invoice to customers for goods or services (...)"
  • I am involved in a project which does accounting, billing, and has apps named like that. Right now I would need to maintain a fork of django-merchant to get around this name clash. Right now Django 1.6 does not check if there is more than one app with the same app label installed, but Django 1.7 will check this and bail out with an error. I know this is just bad luck and might happen with any other package I might want to use in the future. I just want to explain the reason behind creating this issue.

Please rename the module to merchant so it does not confuse new users expecting a merchant or django_merchant module in their PYTHONPATH and stop using the term "billing" in a wrong way.

I might be true to my name, but this really bugged me when I first had a look at django-merchant and was wondering why there is no merchant directory in the sources.

The User-model is not correctly referenced in pin_models.py

Heya,

merchant/billing/models/pin_models.py is referencing the User-model with get_user_model(). This is not allowed inside models and will cause an ImproperlyConfigured-exception.

Fixing this is as easy as:

try:
    from django.contrib.auth import get_user_model
    from django.conf import settings
    User = settings.AUTH_USER_MODEL
except ImportError: # django < 1.5
    from django.contrib.auth.models import User

I removed the else because I didn't saw any reason to use else here.

Don't require global state

The Django community has been interested in finding a way, for a while now, to remove global state from the framework. This is a good pattern to adopt in any API, in practice. For instance:

stripe = get_gateway("stripe", {"API_KEY": "???", ...})

In the above example, the get_gateway method would instantiate the gateway matching the given gateway name with the provided settings. The gateway's __init__ method would be updated to support this. If no settings were provided, the existing merchant_settings = getattr(settings, "MERCHANT_SETTINGS") would take over. The change would be fully backwards compatible.

Should models be bundled?

Lots of the gateways have either redundant columns or make frequent changes in the columns their datatype etc. Should we be bundling models or leave it to the user to decide to pick the columns of his/her choice?

A way to cancel a recurring payment

How can i cancel a reccuring payment? I dont see such option. You can create a reccuring payments but you can`t cancel them, thats strange.

Paypal integration settings issue

When i try to use a paypal offsite integration i run into issue with settings. I need to specify RECEIVER_EMAIL in MERCHANT_SETTINGS for django-merchant.
But in pay_pal_integration.py you do an import.
from paypal.standard.conf import POSTBACK_ENDPOINT, SANDBOX_POSTBACK_ENDPOINT
And in paypal standard.conf there exist this line:
RECEIVER_EMAIL = settings.PAYPAL_RECEIVER_EMAIL
So if i dont specify PAYPAL_RECEIVER_EMAIL in setting too it will be an error.
So basically i need to specify RECEIVER_EMAIL in two places instead of one

Command to test settings

Feature request:

Add a command which will read settings via django.conf and tell if any required settings are missing.

manage.py validatebilling paypal

Gives

You are missing PAYPAL_RECEPIENT_EMAIL in your settings.py (Or blah blah)

Django 1.7 support

With Django==1.7.2 the following Warnings show up when running ./manage.py validate:

System check identified some issues:

WARNINGS:
billing.PinCharge.success: (1_6.W002) BooleanField does not have a default value.
    HINT: Django 1.6 changed the default value of BooleanField from False to None. See https://docs.djangoproject.com/en/1.6/ref/models/fields/#booleanfield for more information.
billing.PinRefund.success: (1_6.W002) BooleanField does not have a default value.
    HINT: Django 1.6 changed the default value of BooleanField from False to None. See https://docs.djangoproject.com/en/1.6/ref/models/fields/#booleanfield for more information.

System check identified 2 issues (0 silenced).

Improve setup

The current setup involves - all or nothing. We need to make it easier to setup individual backends, maybe have a per-backend requirements file?

Standardize the signals for PayPal

Currently, we have not standardized the signals for PayPal according to the merchant convention but making use of the default django-paypal signals.

Should be straight forward as writing wrappers over the existing signals.

Wepay.com support

They have excellent prices and are a startup gaining coverage and beating paypal hands down.

What about adding them.

adding transaction_id, subscription_id as part of standard response dictionary

Given that the various payment processor gateways have widely varying transaction response objects, it would be incredibly helpful to include 'transaction_id' and 'subscription_id' as part of the standard response dictionary.

As an example, here's the implementation for the authorize.net gateway: tinio/merchant@5595448

@theju, if this sounds agreeable and doesn't go against a possible desire to keep the standard response dictionary simple, I'd be happy to implement this for additional gateways, and submit a proper Pull Request.

Thanks.

Update the Authorize.net Gateway docs to use $1

The documentation on:
http://readthedocs.org/docs/django-merchant/en/latest/gateways/authorize_net.html

Shows a transaction using credit card 4222222222222 for $100, which is supposed to succeed.

This is actually a special card # on Authorize.net such that the return code from the API call will be the same value as the card amount. In this case, it's error code 100, which means "The eCheck.Net type is invalid."

I spent about 4 hours debugging the error, wondering if there was in fact some malicious code that would attempt a check transfer. I finally found it was normal behavior for Authorize.net

It seems like a small thing but I highly recommend adjusting the docs. It really throws off someone who's just trying out your project, which actually seems pretty good.

Also, your demo site http://merchant.agiliq.com/authorize/ works, but only if all parameters on the form are filled correctly, otherwise it returns with a 500 error. For people just checking it out, it would be helpful to actually show what working form data would be.

Docs regarding off-site processing are blank

Hi all,

I'll be working to make merchant a default backend for django SHOP, however I cannot seem to find documentation on how to use merchant for off-site processing - docs are blank...
Is this a know problem?

I will be looking forward to contributing to merchant as much as I can, too :)

  • Chris

pluggable app

Hello,

I was setting this app on my local environment and thinking if we could make it pluggable.
say, i would have options to use only braintree for my work so i would not have to run into errors for not configuring the other gateways / integrations.

Can anyone give me suggestion on how we can do this?

This is something like pluggable modules inside an app.

i was looking at this for solutions:

http://www.slideshare.net/coordt/pluggable-django-application-patterns-pycon-2011

can we do this using a UI to select the needed ones? (like a checkbox)

Braintree gateway Authentication Error on production

Hi !

I used django merchant for the sandbox account which worked perfectly. And when I turned to production, a AuthenticationError has been thrown.

I changed the braintree configuration for the production, Braintree say it's correct but I've still this error. I also changed merchant_test_mode to false.

Does someone know about this issue ?

Boto version for Amazon FPS?

It seems Amazon FPS is broken for me. The generated integration link is blank and the test breaks:

./manage.py test billing.AmazonFPSTestCase
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/hakan/Sites/merchant_test/example/billing/tests/amazon_fps_tests.py", line 24, in testLinkGen
self.assertEquals(pregen_link, link.strip())
AssertionError: '<a href="https://authorize.payments-sandbox.amazon.com/cobranded-ui/actions/start?callerKey=AKIAJ2AXTZNZRXZTJWDA&callerReference=100&paymentReason=Digital%20Download&pipelineName=SingleUse&returnURL=http%3A%2F%2Flocalhost%2Ffps%2Ffps-return-url%2F&signature=oSnkew7oCBPVk0IVZAjO87Ogsp4EO7jRlELaFwtqWzY%3D&signatureMethod=HmacSHA256&signatureVersion=2&transactionAmount=30"><img src="http://g-ecx.images-amazon.com/images/G/01/cba/b/p3.gif" alt="Amazon Payments" /></a>' != u'<a href=""><img src="http://g-ecx.images-amazon.com/images/G/01/cba/b/p3.gif" alt="Amazon Payments" /></a>

Further research shows that the issue is in the link_url method of AmazonFPSIntegration here: https://github.com/agiliq/merchant/blob/master/billing/integrations/amazon_fps_integration.py#L58

A call is being make to the make_url method of boto.fps.connection.FPSConnection, which has been renamed to cbui_url in the latest version of boto (2.5.2) (see here: https://github.com/boto/boto/blob/develop/boto/fps/connection.py#L198 and here: boto/boto@d4e1d22#L2L174)

What version of boto should we be using to use django-merchant? It would be helpful to include version information alongside the requirements in the documentation.

Improve the form billing/forms/AuthorizeNetDPMForm

  1. The form includes x_amount, which is useless at this point. The thing is, the hash value has already been computed using amount=$1, and changing it at this point leads Authorize.Net to reject the transaction. The easiest solution is to make the amount readonly by default to at least hint the developers that they have to get it at some previous page and pass along:
    x_amount = forms.CharField(label="Amount (in USD)", widget=forms.TextInput(attrs={'readonly':'readonly'}))
  2. The form includes x_relay_response, which is a yes/no thing, but not a x_relay_url, which you may want to pass along. (Of course, another option is to configure it in Authorize.net).
    Example: x_relay_url = forms.CharField(widget=forms.HiddenInput())
  3. It may be useful to add a hidden x_cust_id (customer id) as e.g.
    x_cust_id = forms.CharField(widget=forms.HiddenInput(), required=True)
    (or without required=True). I would imagine that many applications associate transactions with particular Django users.
  4. The form is somewhat inflexible. I would actually like to collect the address data on a previous page and to save this information. However, I don't want then to redisplay the entire form to the customer, even with the address prefilled.

I probably could create an instance of this form and then change it dynamically and/or inherit my own class from this form, but then I also need to tell the template tag to display my form. Some ideas:

  • Allow to overload the form by e.g. combining it with a mixin adding a couple extra fields and point to the right form somewhere in the config,
    and/or
  • Allow helper methods for hiding particular fields from a form and passing certain other key/value pairs along as hidden fields.

Pass more information with the signals transaction_was_successful, transaction_was_unsuccessful

Right now when the signals get triggered in billing/integrations/authorize_net_dpm_integration.py, very little information is passed along. It passes the string "sale", which is kind of misleading, and a string describing the transaction. The string describing the transaction (result) usually says something like "This transaction cannot be accepted", without mentioning that there are actually x_response_code and x_response_reason_text available.
Also, right now I have donations, not sales, so I don't want the word "sale" to appear even in the code ;-))

On the other hand, it is not passing the transaction amount, nor the transaction id, nor the cusomer id. However, this is the kind of information I need to record the transaction as a Django model, the only clean way of doing it is using this signal. Thus, I ended up passing the entire request object. I know that this ends up being Authorize.net--dependent, but it may still be good to pass it along so that one does not end up editing the code or creating a branch just for that. Of course, it would also be nice to try and pass amount, transaction_id, etc., but then it has to be done for all payment systems.

Keyerror exception using Paypal Gateway

Hello, is trying of using the example of documentation: http://django-merchant.readthedocs.org/en/latest/gateways/paypal_gateway.html, but when i run the command: response1 = g1.purchase(100, cc, options = {...}), displays the following error:

 42         params['expdate'] = '%02d%04d' % (credit_card.month, credit_card.year)
 43         params['cvv2'] = credit_card.verification_value
 44         params['ipaddress'] = options['request'].META.get("REMOTE_ADDR", "")
 45         params['amt'] = money
 46 

KeyError: 'request'

Thank you (Y)

Refactor get_gateway, get_integration logic

Right now, get_gateway and get_integration are a bit magical. If we want foo backend, we're looking for app.gateways.foo.FooGateway in all installed apps. In addition to being inefficient, it has a chance of causing unintended consequences due to layout of other installed apps. The only benefit is that we allow users to define custom backends by following the above convention.

Instead, I propose we should have a setting similar to CACHES e.g MERCHANT_GATEWAYS with key being the gateway name and value being the dotted path to the gateway class. Then get_gateway could simply load the class pointed at by the path. This will allow more flexibility in creating and laying out custom backends.

Same goes for integrations.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.