8000 Add a Manual External Payment Integration by FinnIckler · Pull Request #11299 · thewca/worldcubeassociation.org · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Add a Manual External Payment Integration #11299

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 61 commits into
base: main
Choose a base branch
from

Conversation

FinnIckler
Copy link
Member

Replacement for #9737

This is still WIP because I didn't add any DB changes yet. I would like to have some feedback on this before.

I could not use the already existing connect_payment_integration method because that requires a redirect, which doesn't work in react world. I also think it doesn't really make sense, because there are no accounts to save.

I added a new page to input the payment information text and needed payment reference instead.

@FinnIckler
Copy link
Member Author

image
image

There are still a ton of small changes to be made, like adding to the CSV export and changing the single registration edit page

@FinnIckler
Copy link
Member Author

Payment step during the registration:
image

Payment step after payment:
image

@FinnIckler FinnIckler marked this pull request as ready for review April 10, 2025 16:01
@gregorbg
Copy link
Member

(for the record: I had a lengthy discussion with Finn during our regular call, there are gonna be major reworks on this PR)

@gregorbg gregorbg marked this pull request as draft April 14, 2025 09:39
@FinnIckler
Copy link
Member Author

you had a typo there :P

@dunkOnIT
Copy link
Contributor
dunkOnIT commented May 1, 2025

@thewca-bot deploy staging

@FinnIckler
Copy link
Member Author

I just noticed that we need to implement showing the payment reference in the admin table again

flash[:error] = 'PayPal is not yet available in production environments'
return redirect_to competitions_payment_setup_path(competition)
end

connector = CompetitionPaymentIntegration::AVAILABLE_INTEGRATIONS[payment_integration.to_sym].safe_constantize
account_reference = connector&.connect_account(params)
if CompetitionPaymentIntegration::AVAILABLE_INTEGRATIONS[payment_integration].nil?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to check for the validity of the integration here, before we try and assign it to a variable. Old-line 284 actually fails if the integration is unrecognized because safe_constantize can't be called on nil


competition.competition_payment_integrations.new(connected_account: account_reference)
raise ActionController::RoutingError.new("No integration reference submitted") if integration_reference.blank?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wording on the old message was incorrect - it wasn't checking for the payment integration type, it was checking for the presence of the account reference

@dunkOnIT
Copy link
Contributor
dunkOnIT commented May 4, 2025

Had inconsistent behaviour when trying to use this via the UI (sometimes the payment amount was showing 2x the competition's fees, other times it was failing outright), so adding tests to assert the backend behaviour

@dunkOnIT
Copy link
Contributor
dunkOnIT commented May 4, 2025

Two related notes on the implementation here:

  • Should we be storing amount_iso and currency_code on the payment record? I'm not a big fan of this given that we're only inferring the information from the competition's settings, and so are very likely to end up in the situation where we're making confident assertions about payments amounts that are incorrect (already, I can give the example of CubingZA, who charge different amounts through their external payment service based on the number of days the competitor is attending the competition
    • At the very least, I'd say we shouldn't show this info to the user if there's some technological reason why it has to be stored (eg, we expect all payment_records to have those fields). But if we aren't showing it to the user, I'd again make the case that we should try not to store it at all
  • EDIT: Yes we do I wasn't thinking in enough detail about how our payment flow works. Do we need to/should we be creating a PaymentIntent for manual payments? It seems like all we need to be doing is checking/asserting the presence of a PaymentRecord, so the PaymentIntent seems redundant. At the same time, I recognize that we don't want to deviate from the current workflow too much, so this might well be a very shortsighted thought.

has_one :payment_intent, as: :payment_record

def determine_wca_status
WCA_TO_MANUAL_PAYMENT_STATUS_MAP[status.to_sym]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This used to have the same contents as status - I've changed it to pull the wca_status from the defined mapping

errors.add(:wca_status, "#{wca_status} is not compatible with PaypalRecord status: #{payment_record.paypal_status}") unless
PaypalRecord::WCA_TO_PAYPAL_STATUS_MAP[wca_status.to_sym].include?(payment_record.paypal_status)
when 'ManualPaymentRecord'
errors.add(:wca_status, "#{wca_status} is not compatible with ManualPaymentRecord status: #{payment_record.status}") unless
ManualPaymentRecord::WCA_TO_MANUAL_PAYMENT_STATUS_MAP[wca_status.to_sym].include?(payment_record.status)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previously this was calling payment_record.paypal_status - updated to just call status of the payment_record itself

get api_v1_registrations_payment_ticket_path(competition_id: competition.id), headers: headers
expect(response).to be_successful
end
context 'stripe connect payment integration' do
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved everything that was here into this context block, and added a new context block for manual payment integrations - this makes the diff appear larger/more significant than it is

@FinnIckler
Copy link
Member Author

image
Added the Payment Reference back to the Administration Panel

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0