Topic on Talk:Fundraising tech/Ingenico Connect

payment_processor_type = the actual processor, like paypal standard, paypal express

• labels and defaults for a bunch of password / url settings

• need to add rows for ingenico webcollect, ingenico connect, adyen, amazon, d*local

payment_processor = a specific account with a payment processor

payment_token = a token for a specific donor and a specific account

required fields in civicrm_payment_token table:

• contact_id (fk)

• payment_processor_id (fk)

• token (string)

• created_date (date)

Foreign keys to payment_processor exist in these tables:

• civicrm_contribution_recur

• civicrm_financial_trxn

• civicrm_payment_token

OK, so we should add our payment processor accounts to the payment_processor table...

1. insert missing payment_processor_types (What to use for an implementation class here? dummy?)
2. insert payment_processor rows
3. insert account_relationship rows
4. Update civicrm_financial_trxn based on gateway column in wmf_contribution_extra
5. Use API methods to get and create PaymentToken objects when we need to

civicrm_payment_token is a table in civicrm that is a reference to the account information for a payment_processor. Meanwhile, the token field in the civicrm_payment_token table is the string reference to the token for the recurring payment.

Payment classes are subclasses of CRM/Core/Payment. There is also CRM/Core/DummyPayment (not exact), which we could subclass. Could we somehow link this to our custom code in our extension though? For globalcollect, we use the recurring_globalcollect extension (that is the only payment processor that runs recurring payments from the civi database).