Business Workflow Map

provider-backed payment checkout and callback handling

What this workflow does

Application code builds a provider-specific checkout form, redirects the user or returns hidden fields, then handles callback processing to update payment state and return success/failure outcomes.

Why this workflow matters

• creates a gateway-ready payment form
• directs the customer to the correct payment/callback URL
• enables provider implementations to update payment status and amounts

Implementation references

• BasicProvider.capture() payments/core.py · lines 146–147
• BasicProvider.release() payments/core.py · lines 149–150
• BasicProvider.refund() payments/core.py · lines 152–153
• BasicProvider.cancel() payments/core.py · lines 155–156
• BasicProvider.get_action() payments/core.py · lines 70–72
• BasicProvider.get_token_from_request() payments/core.py · lines 117–119
• BasicProvider.__init__() payments/core.py · lines 74–80
• BasicProvider.get_hidden_fields() payments/core.py · lines 82–91
• BasicProvider.get_form() payments/core.py · lines 93–103
• BasicProvider.process_data() payments/core.py · lines 105–115
• _default_provider_factory() payments/core.py · lines 162–177
• BasicProvider.get_return_url() payments/core.py · lines 121–144
• get_payment_model() payments/__init__.py · lines 86–103
• PaymentStatus payments/__init__.py · lines 30–49
• MercadoPagoProvider.create_preference() payments/mercadopago/__init__.py · lines 74–122
• StripeProviderV3.get_form() payments/stripe/providers.py · lines 98–113
• MercadoPagoProvider.get_form() payments/mercadopago/__init__.py · lines 189–198
• DummyProvider.process_data() payments/dummy/__init__.py · lines 60–67
• MercadoPagoProvider.process_callback() payments/mercadopago/__init__.py · lines 150–158
• MercadoPagoProvider.process_notification() payments/mercadopago/__init__.py · lines 128–148
• StripeProviderV3.process_data() payments/stripe/providers.py · lines 243–268
• DummyProvider.get_form() payments/dummy/__init__.py · lines 26–58
• MercadoPagoProvider payments/mercadopago/__init__.py · lines 38–218
• StripeProviderV3.create_session() payments/stripe/providers.py · lines 115–146
• PaymentError.__init__() payments/__init__.py · lines 71–79
• get_base_url() payments/core.py · lines 32–57
• DummyProvider payments/dummy/__init__.py · lines 16–81
• StripeProviderV3 payments/stripe/providers.py · lines 73–268

card payment authorization and capture via Authorize.Net

What this workflow does

Authorize.Net provider posts card data to the gateway, updates payment status from waiting/input to confirmed or error, and redirects to the success URL on valid input.

Why this workflow matters

• successful approval creates a confirmed payment
• declined or errored card input surfaces a form error message
• transaction id is stored for the approved charge
• caller is redirected to the success URL on valid form submission

Implementation references

• AuthorizeNetProvider.__init__() payments/authorizenet/__init__.py · lines 28–42
• AuthorizeNetProvider payments/authorizenet/__init__.py · lines 14–90
• PaymentForm payments/authorizenet/forms.py · lines 12–39
• AuthorizeNetProvider.get_form() payments/authorizenet/__init__.py · lines 81–87
• PaymentForm.clean() payments/authorizenet/forms.py · lines 13–39
• BasePayment payments/models.py · lines 49–274
• AuthorizeNetProvider.get_payment_response() payments/authorizenet/__init__.py · lines 77–79
• test_provider_redirects_to_success_on_payment_success() payments/authorizenet/test_authorizenet.py · lines 59–81

card payment authorization and settlement

What this workflow does

Braintree payment form collects card data, submits a gateway sale, then captures and confirms the payment before redirecting to the success URL.

Why this workflow matters

• payment is settled with the gateway
• payment state becomes CONFIRMED
• captured amount is recorded
• caller is redirected to the success page

Implementation references

• BraintreeProvider.__init__() payments/braintree/__init__.py · lines 26–50
• BraintreeProvider.get_form() payments/braintree/__init__.py · lines 52–59
• BraintreePaymentForm.clean() payments/braintree/forms.py · lines 12–33
• BraintreePaymentForm.save() payments/braintree/forms.py · lines 64–68
• BasePayment payments/models.py · lines 49–274
• test_provider_redirects_to_success_on_payment_success() payments/braintree/test_braintree.py · lines 55–72
• BraintreeProvider payments/braintree/__init__.py · lines 13–59
• BraintreePaymentForm payments/braintree/forms.py · lines 9–68
• test_provider_shows_validation_error_message() payments/braintree/test_braintree.py · lines 75–89

Provider-specific payment request composition and callback verification

What this workflow does

Dotpay and Coinbase providers build provider-specific payment requests and reconcile callbacks by verifying signatures or custom tokens before confirming or rejecting the payment.

Why this workflow matters

• Produces provider-specific redirect/form payloads
• Rejects malformed or forged callback data
• Confirms completed payments and records transaction identifiers

Implementation references

• DotpayProvider payments/dotpay/__init__.py · lines 16–105
• CoinbaseProvider payments/coinbase/__init__.py · lines 18–97
• CoinbaseProvider.get_checkout_code() payments/coinbase/__init__.py · lines 47–75
• DotpayProvider.process_data() payments/dotpay/__init__.py · lines 98–105
• ProcessPaymentForm.save() payments/dotpay/forms.py · lines 93–101
• CoinbaseProvider.process_data() payments/coinbase/__init__.py · lines 84–97
• ProcessPaymentForm.clean() payments/dotpay/forms.py · lines 51–91
• CoinbaseProvider.get_custom_token() payments/coinbase/__init__.py · lines 43–45
• test_process_data_payment_accepted() payments/dotpay/test_dotpay.py · lines 96–109
• test_incorrect_process_data() payments/dotpay/test_dotpay.py · lines 130–135
• test_process_data() payments/coinbase/test_coinbase.py · lines 65–71
• test_incorrect_custom_token_process_data() payments/coinbase/test_coinbase.py · lines 74–83
• ProcessPaymentForm payments/dotpay/forms.py · lines 17–101
• test_get_hidden_fields() payments/dotpay/test_dotpay.py · lines 91–93
• test_process_data_payment_rejected() payments/dotpay/test_dotpay.py · lines 112–127
• test_incorrect_data_process_data() payments/coinbase/test_coinbase.py · lines 86–93

PayPal checkout and post-payment reconciliation

What this workflow does

PayPal provider creates or reuses checkout sessions, redirects the user, then processes the return/callback to capture, preauthorize, refund, or reject the payment.

Why this workflow matters

• Creates redirectable checkout sessions
• Confirms, preauthorizes, refunds, or rejects payment records
• Persists API response data for later reconciliation

Implementation references

• PaypalProvider payments/paypal/__init__.py · lines 62–380
• test_provider_raises_redirect_needed_on_success() payments/paypal/test_paypal.py · lines 213–239
• PaypalProvider.get_access_token() payments/paypal/__init__.py · lines 198–225
• PaypalProvider.get_form() payments/paypal/__init__.py · lines 272–284
• PaypalProvider.capture() payments/paypal/__init__.py · lines 331–360
• PaypalProvider.process_data() payments/paypal/__init__.py · lines 286–313
• authorize.wrapper() payments/paypal/__init__.py · lines 37–57
• test_provider_renews_access_token() payments/paypal/test_paypal.py · lines 434–466
• test_provider_request_without_payerid_redirects_on_failure() payments/paypal/test_paypal.py · lines 422–431
• PaypalProvider.refund() payments/paypal/__init__.py · lines 367–380
• Payment payments/paypal/test_paypal.py · lines 91–196
• test_provider_captures_payment() payments/paypal/test_paypal.py · lines 242–262
• test_provider_refunds_payment_fully() payments/paypal/test_paypal.py · lines 278–307
• authorize() payments/paypal/__init__.py · lines 36–59

gateway-specific checkout callback handling

What this workflow does

CyberSource and Sagepay provider flows create gateway requests, process gateway callbacks, and move payment state to confirmed, preauth, rejected, or error depending on gateway outcome.

Why this workflow matters

• handles 3-D Secure or encrypted return flows
• updates fraud and payment status based on gateway reason/status codes
• stores transaction identifiers and payment metadata
• routes the user to success or failure depending on outcome

Implementation references

• CyberSourceProvider payments/cybersource/__init__.py · lines 44–502
• CyberSourceProvider.process_data() payments/cybersource/__init__.py · lines 472–502
• SagepayProvider payments/sagepay/__init__.py · lines 24–141
• SagepayProvider.get_hidden_fields() payments/sagepay/__init__.py · lines 83–118
• SagepayProvider.process_data() payments/sagepay/__init__.py · lines 120–141
• BasePayment payments/models.py · lines 49–274
• CyberSourceProvider.charge() payments/cybersource/__init__.py · lines 167–194
• CyberSourceProvider._set_proper_payment_status_from_reason_code() payments/cybersource/__init__.py · lines 118–165
• CyberSourceProvider._change_status_to_confirmed() payments/cybersource/__init__.py · lines 111–116
• CyberSourceProvider.__init__() payments/cybersource/__init__.py · lines 63–98
• test_provider_raises_redirect_needed_on_success() payments/sofort/test_sofort.py · lines 54–69
• test_provider_redirects_on_success() payments/sofort/test_sofort.py · lines 72–96

Process provider callback to update a payment record

What this workflow does

Django payment callback route locks a payment row, resolves the configured provider, and delegates asynchronous callback processing to update payment state.

Why this workflow matters

• Prevents concurrent callback races
• Updates the canonical payment record from provider data
• Returns a deterministic response for the callback caller

Implementation references

• process_data() payments/urls.py · lines 28–52
• ProcessDataLockingTestCase payments/test_urls.py · lines 91–115
• ProcessDataLockingTestCase.test_process_data_locks_the_payment_row() payments/test_urls.py · lines 94–115
• CoinbaseProvider.process_data() payments/coinbase/__init__.py · lines 84–97
• DotpayProvider.process_data() payments/dotpay/__init__.py · lines 98–105
• static_callback() payments/urls.py · lines 55–98
• StaticCallbackTestCase.test_payment_not_found_returns_json_404() payments/test_urls.py · lines 66–88
• StaticCallbackTestCase.test_invalid_provider_variant_returns_json_400() payments/test_urls.py · lines 20–29