From aa8e45364b20e3862d300d3cb37aeb9572ea1bdd Mon Sep 17 00:00:00 2001
From: Eileen McNaughton <eileen@mcnaughty.com>
Date: Tue, 13 Nov 2018 09:02:35 +1300
Subject: [PATCH] Ripped out some old stuff
---
docs/extensions/payment-processors/index.md | 38 +++++----------------
1 file changed, 9 insertions(+), 29 deletions(-)
diff --git a/docs/extensions/payment-processors/index.md b/docs/extensions/payment-processors/index.md
index fd9296f1..22d6ceb4 100644
--- a/docs/extensions/payment-processors/index.md
+++ b/docs/extensions/payment-processors/index.md
@@ -30,7 +30,8 @@ fields in the user form.
**Billing Mode** is a CiviCRM-specific classification of different types
of payment processing: 'form', 'button', or 'notify'. These determine
-the user workflow required and how the CiviCRM code works.
+the user workflow required and how the CiviCRM code works. The concept is
+mostly obsolete now.
## Processors
@@ -84,9 +85,8 @@ the directory `CRM/Core/Payment` that subclasses this abstract class. Any
extensions that provide a payment processor have to provide a
corresponding subclass file in their own `CRM/Core/Payment directory`.
-The key method defined by the payment-processor-specific payment class
-depends on the [billing mode](/extensions/payment-processors/types.md).
-This is roughly documented in the page on [creating a payment processor](/extensions/payment-processors/create.md)
+The key methods are roughly documented in the page on [creating a payment processor](/extensions/payment-processors/create.md)
+but the main method for all processors to implement is `doPayment`
The payment object is used in several places in the CiviCRM code base.
It's intention is to encapsulate all the details of processing a
@@ -95,32 +95,12 @@ donations, a payment for a membership, a payment for an event, and some
combination of those (e.g. a recurring series of payments for an
auto-renewed membership).
-The way that payment objects get created is a bit convoluted. The
-payment objects are not created with the typical `new ClassName()`
-command, but use a mangled version of the singleton pattern to create
-new payment objects, with no more than one per mix of mode, payment
-processor, and whether it's attached to a form. Specifically, they get
-created with this kind of thing:
+The way that payment objects get created historically was a bit convoluted.
+They are mostly now created by the \Civi\Payment\System
-`$paymentObject = CRM_Core_Payment::singleton($mode, $paymentProcessor, $paymentForm);`
-
-Inside the singleton function,
-`$cacheKey = "{$mode}_{$paymentProcessor['id']}_" . (int)isset($paymentForm);`
-
-So that means we are creating unique payment objects per distinct value
-of: `mode + payment processor id + <is it associated with a payment
-form>`, where 'mode' in this case just means test or not (not the
-"billing mode"!).
-
-The paymentProcessor object is just the simple BAO object of fields from
-the corresponding database table, and the singleton function then finds
-the classname of the processor, and runs the singleton function of that
-class to create the actual payment object that subclasses the abstract
-CRM_Core_Payment class.
-
-At the end of this process, you have a payment object that includes
-payment processor specific methods and a reasonably simple payment
-processor object attached to it.
+Due to the historical complexity we sometimes use the id of the
+live processor in test mode for the test processor although
+where possible we use the id of the test processor itself.
## Payment Processor Objects, and in the Database
--
GitLab