Files
Antoine Vandevenne (anv) 6858d5ca49 [IMP] payment, *: document technical details in README files
Each payment acquirer has its own implementation specificities: some
implement a 'payment with redirection' flow and others a 'direct payment
flow'; sometimes the 'payment with redirection' flow is even implemented
as a 'direct payment' flow through an iframe; one payment acquirer could
support webhooks while another does not and relies on another mechanism
to fetch payment status updates...

It can be tricky to guess where to look in the code to determine how a
payment acquirer is implemented.

On top of that, the online payments ecosystem evolves at a fast pace due
to competition, buyouts, and legislation enforcement. Acquirers are thus
frequently migrated to new APIs that might differ in implementation from
the previous API.

To help figure out the *which*, *why*, *how*, and *when* of payment API
implementations, a README.md file is added to the main directory of all
payment acquirer modules. They can be browsed in human-readable format
on GitHub.

task-2374916

closes odoo/odoo#156084

X-original-commit: 4c19f26df3d39394cce2f183d6df15c5b89c7d27
Related: odoo/enterprise#57921
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
2024-03-04 15:15:54 +00:00

21 lines
668 B
Python

# Part of Odoo. See LICENSE file for full copyright and licensing details.
{
'name': "Payment Provider: Flutterwave",
'version': '1.0',
'category': 'Accounting/Payment Providers',
'sequence': 350,
'summary': "A Nigerian payment provider covering several African countries.",
'description': " ", # Non-empty string to avoid loading the README file.
'depends': ['payment'],
'data': [
'views/payment_flutterwave_templates.xml',
'views/payment_provider_views.xml',
'data/payment_provider_data.xml',
],
'post_init_hook': 'post_init_hook',
'uninstall_hook': 'uninstall_hook',
'license': 'LGPL-3',
}