You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

how_to_integrate_payment.rst 4.7KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105
  1. ========================
  2. How to integrate payment
  3. ========================
  4. Oscar is designed to be very flexible around payment. It supports paying for an
  5. order with multiple payment sources and settling these sources at different
  6. times.
  7. Models
  8. ------
  9. The payment app provides several models to track payments:
  10. * ``SourceType`` - This is the type of payment source used (eg PayPal, DataCash, BrainTree). As part of setting up
  11. a new Oscar site you would create a SourceType for each of the payment
  12. gateways you are using.
  13. * ``Source`` - A source of payment for a single order. This tracks how an order
  14. was paid for. The source object distinguishes between allocations, debits and
  15. refunds to allow for two-phase payment model. When an order is paid for by
  16. multiple methods, you create multiple sources for the order.
  17. * ``Transaction`` - A transaction against a source. These models provide better
  18. audit for all the individual transactions associated with an order.
  19. Example
  20. -------
  21. Consider a simple situation where all orders are paid for by PayPal using their
  22. 'SALE' mode where the money is settled immediately (one-phase payment model).
  23. The project would have a 'PayPal' SourceType and, for each order, create a new
  24. ``Source`` instance where the ``amount_debited`` would be the order total. A
  25. ``Transaction`` model with ``txn_type=Transaction.DEBIT`` would normally also be
  26. created (although this is optional).
  27. This situation is implemented within the sandbox site for the
  28. django-oscar-paypal_ extension. Please use that as a reference.
  29. See also the sandbox for django-oscar-datacash_ which follows a similar pattern.
  30. .. _django-oscar-paypal: https://github.com/tangentlabs/django-oscar-paypal/tree/master/sandbox
  31. .. _django-oscar-datacash: https://github.com/tangentlabs/django-oscar-datacash/tree/master/sandbox
  32. Integration into checkout
  33. -------------------------
  34. By default, Oscar's checkout does not provide any payment integration as it is
  35. domain-specific. However, the core checkout classes provide methods for
  36. communicating with payment gateways and creating the appropriate payment models.
  37. Payment logic is normally implemented by using a customised version of
  38. ``PaymentDetailsView``, where the ``handle_payment`` method is overridden. This
  39. method will be given the order number and order total plus any custom keyword
  40. arguments initially passed to ``submit`` (as ``payment_kwargs``). If payment is
  41. successful, then nothing needs to be returned. However, Oscar defines a few
  42. common exceptions which can occur:
  43. * ``oscar.apps.payment.exceptions.RedirectRequired`` For payment integrations
  44. that require redirecting the user to a 3rd-party site. This exception class
  45. has a ``url`` attribute that needs to be set.
  46. * ``oscar.apps.payment.exceptions.UnableToTakePayment`` For *anticipated* payment
  47. problems such as invalid bankcard number, not enough funds in account - that kind
  48. of thing.
  49. * ``oscar.apps.payment.exceptions.PaymentError`` For *unanticipated* payment
  50. errors such as the payment gateway not responding or being badly configured.
  51. When payment has completed, there's a few things to do:
  52. * Create the appropriate ``oscar.apps.payment.models.Source`` instance and pass
  53. it to ``add_payment_source``. The instance is passed unsaved as it requires a
  54. valid order instance to foreign key to. Once the order is placed (and an
  55. order instance is created), the payment source instances will be saved.
  56. * Record a 'payment event' so your application can track which lines have been
  57. paid for. The ``add_payment_event`` method assumes all lines are paid for by
  58. the passed event type, as this is the normal situation when placing an order.
  59. Note that payment events don't distinguish between different sources.
  60. For example::
  61. from oscar.apps.checkout import views
  62. from oscar.apps.payment import models
  63. # Subclass the core Oscar view so we can customise
  64. class PaymentDetailsView(views.PaymentDetailsView):
  65. def handle_payment(self, order_number, total, **kwargs):
  66. # Talk to payment gateway. If unsuccessful/error, raise a
  67. # PaymentError exception which we allow to percolate up to be caught
  68. # and handled by the core PaymentDetailsView.
  69. reference = gateway.pre_auth(order_number, total.incl_tax, kwargs['bankcard'])
  70. # Payment successful! Record payment source
  71. source_type, __ = models.SourceType.objects.get_or_create(
  72. name="SomeGateway")
  73. source = models.Source(
  74. source_type=source_type,
  75. amount_allocated=total.incl_tax,
  76. reference=reference)
  77. self.add_payment_source(source)
  78. # Record payment event
  79. self.add_payment_event('pre-auth', total.incl_tax)