Payment

The payment app contains models that capture how orders are paid for. It does not have any views.

Abstract models

class oscar.apps.payment.abstract_models.AbstractBankcard(*args, **kwargs)

Model representing a user’s bankcard. This is used for two purposes:

1. The bankcard form will return an instance of this model that can be used with payment gateways. In this scenario, the instance will have additional attributes (start_date, issue_number, ccv) that payment gateways need but that we don’t save.

2. To keep a record of a user’s bankcards and allow them to be re-used. This is normally done using the ‘partner reference’.

Warning

Some of the fields of this model (name, expiry_date) are considered “cardholder data” under PCI DSS v2. Hence, if you use this model and store those fields then the requirements for PCI compliance will be more stringent.

save(*args, **kwargs)

Save the current instance. Override this in a subclass if you want to control the saving process.

The ‘force_insert’ and ‘force_update’ parameters can be used to insist that the “save” must be an SQL insert or update (or equivalent for non-SQL backends), respectively. Normally, they should not be set.

class oscar.apps.payment.abstract_models.AbstractSource(*args, **kwargs)

A source of payment for an order.

This is normally a credit card which has been pre-authorised for the order amount, but some applications will allow orders to be paid for using multiple sources such as cheque, credit accounts, gift cards. Each payment source will have its own entry.

This source object tracks how much money has been authorised, debited and refunded, which is useful when payment takes place in multiple stages.

allocate(amount, reference='', status='')

Convenience method for ring-fencing money against this source

property amount_available_for_refund

Return the amount available to be refunded

property balance

Return the balance of this source

create_deferred_transaction(txn_type, amount, reference=None, status=None)

Register the data for a transaction that can’t be created yet due to FK constraints. This happens at checkout where create an payment source and a transaction but can’t save them until the order model exists.

debit(amount=None, reference='', status='')

Convenience method for recording debits against this source

refund(amount, reference='', status='')

Convenience method for recording refunds against this source

save(*args, **kwargs)

Save the current instance. Override this in a subclass if you want to control the saving process.

The ‘force_insert’ and ‘force_update’ parameters can be used to insist that the “save” must be an SQL insert or update (or equivalent for non-SQL backends), respectively. Normally, they should not be set.

class oscar.apps.payment.abstract_models.AbstractSourceType(*args, **kwargs)

A type of payment source.

This could be an external partner like PayPal or DataCash, or an internal source such as a managed account.

class oscar.apps.payment.abstract_models.AbstractTransaction(*args, **kwargs)

A transaction for a particular payment source.

These are similar to the payment events within the order app but model a slightly different aspect of payment. Crucially, payment sources and transactions have nothing to do with the lines of the order while payment events do.

For example: * A pre-auth with a bankcard gateway * A settle with a credit provider (see django-oscar-accounts)