Openpay is an online gateway to execute online payments using debit/credit cards or bank transferences. Openpay allows to create Plans for system memberships, with an autocharge system.
Django-Openpay is a django application created to wrap the current library of Openpay for Python. Django-Openpay integrates two Openpay libraries:
-
The Python library to manage Plans, Charges, Subscriptions, Customers and Cards (partially) directly through django models.
-
The JavaScript library to manage payouts, transfers and cards without saving sensitive information in your django application. (Giving us the relief of not having to make our Django system PCI Compliant)
-
Create directly from Django into Openpay:
- Customers
- Plans
- Subscriptions
- Charges
-
Delete directly from Django into Openpay:
- Customers
- Plans
- Subscriptions
- Cards
-
Create from JSX into Openpay:
- Cards
-
Reflect updates through webhooks from Openpay into Django:
- Charges
-
Refund or Capture Charges.
To install this package from pip it is required to execute:
pip install django-openpay
This package includes JSX and JS files to be able to use the JavaScript library without further delay.
To use the JSX files, you should have Webpack or Gulp installed to compile the
JSX to ES5 or ES6. But due to my inexperience for including NPM dependencies
in pip packages, you will require to install react
and react-dom
by
hand. Although we could have used the Node package of Openpay and prevent some
manual configuration, we have no idea of how the security is managed inside
the Node package to be used directly from front-end.
To use the JSX file, be sure to include in your HTML head:
<script type='text/javascript' src='https://code.jquery.com/jquery-3.1.0.min.js'></script>
<script type='text/javascript' src='https://openpay.s3.amazonaws.com/openpay.v1.min.js'></script>
<script type='text/javascript' src='https://openpay.s3.amazonaws.com/openpay-data.v1.min.js'></script>
This package requires to have knowledge of your Openpay's public, private and
merchant keys. To do this you just have to put your keys inside the
settings.py
file of your Django project using the following variables:
OPENPAY_PRIVATE_API_KEY='string'
OPENPAY_PUBLIC_API_KEY='string'
OPENPAY_MERCHANT_ID='string'
OPENPAY_VERIFY_SSL=True # or False
OPENPAY_DEVICE_ID='string'
OPENPAY_CUSTOMER_MODEL='string'
The AbstractCustomer
model is a model which can be inherited from. This was
done because you may want to make your User
model the customer, or manage a
team of users as one customer. It is up to you, just remember to use all the
fields described in the abstract, or (in case you want to rename the fields)
set them to None
and overwrite the pull
and push
methods.
Then you will have to run the python manage.py makemigrations
command. This
is necessary due to the problem that there is no default Customer
model,
until you inherit from the AbstractCustomer
and declare it inside the
settings.py variable OPENPAY_CUSTOMER_MODEL
.
In order to be able to use the Webhooks feature, you need to link your Openpay
project to a specific url of your project (which calls the
'django_openpay.views.webhook'
view), inside the Openpay system. Remember
that this package tries to make everything as secure as possible and, for that
same reason, you need to activate the BasicAuth option in the Openpay system
when you are creating the webhook, using a username and a password (it must NOT
be a Django user). That same username and password will be added directly in
your django settings file inside the the variable OPENPAY_BASICAUTH_USERS
.
This variable should be used like:
OPENPAY_BASICAUTH_USERS = {
"username": "password"
}
django-openpay doesn't save critical information in its django models. All the information that can be saved inside the models without needing to be PCI Compliant is being saved. The most sensitive information is being accessed from the Openpay servers by using access tokens.
django-openpay has not been tested for security vulnerabilities yet and does not have an SSL certificate preconfiguration, this is the reason behind our decision to be able to create cards only in the front-end.