solidusio/solidus_paypal_commerce_platform

💳 Integrate Solidus with Paypal Commerce Platform

solidus_paypal_commerce_platform's Issues

Users can check out with invalid payment

Steps:

1. Proceed to payment step on a frontend order
2. Using the javascript console, set the value of the hidden paypal_order_id field to a random string: $(".payments_source_paypal_order_id").val("random_string")
3. Hit the save and continue button
4. On the confirm page, hit complete checkout
5. An error page is thrown, but refresh the page and your order will be completed successfully.

I think failing the payment on PayPals error response (when completing the order) is the way to handle this.

Admin users have the option to edit payment amount

On an uncaptured payment, admin users can change the amount that the customer is being charged on the Payment object. However, this does not affect the amount that PayPal actually charges.

gateway.rb does not allow for nil auto-capture

Pull Request: Void-Space-Technologies/solidus_paypal_commerce_platform@master...fix-nil-auto-capture
file: app/models/solidus_paypal_commerce_platform/gateway.rb
method: create_order
code:

    def create_order(order, auto_capture)
      intent = auto_capture ? "CAPTURE" : "AUTHORIZE"
      request = OrdersCreateRequest.new
      paypal_order = SolidusPaypalCommercePlatform::PaypalOrder.new(order)
      request.request_body paypal_order.to_json(intent)
      @client.execute(request)
    end

issue: If, in the admin panel, the Auto Capture for PayPal is set to Use app default (see photo below), then there is possibility for errors.

explanation: This is because the first line in the create_order method (intent = auto_capture ? "CAPTURE" : "AUTHORIZE") assumes that the auto_capture argument will either be true or false when in reality it can be true, false, or nil (if nil then we should be using Spree::Config.auto_capture).

nuanced error: If, in the admin panel, the Auto Capture for PayPal is set to Use app default and the app default (Spree::Config.auto_capture) is set to true, then the create_order method (in its current form) will send "AUTHORIZE" to PayPal when really is should be sending "CAPTURE" to PayPal. So PayPal will authorize but will not capture. This causes a payment error during payment checkout which I am assuming is because solidus is expecting PayPal to capture, but PayPal did not.

suggested solution (see below or view pull request here):

    def create_order(order, auto_capture)
      auto_capture = Spree::Config.auto_capture if auto_capture.nil? # New line of code
      intent = auto_capture ? "CAPTURE" : "AUTHORIZE"
      request = OrdersCreateRequest.new
      paypal_order = SolidusPaypalCommercePlatform::PaypalOrder.new(order)
      request.request_body paypal_order.to_json(intent)
      @client.execute(request)
    end

NOTE for this to work, the javascript_sdk_url method in payment_method.rb file (app/models/solidus_paypal_commerce_platform/payment_method.rb) needs to be updated as well:

    def javascript_sdk_url(order: nil, currency: nil)
      auto_capture = Spree::Config.auto_capture if auto_capture.nil? # New line of code
      # Both instance and class respond to checkout_steps.
      step_names = order ? order.checkout_steps : ::Spree::Order.checkout_steps.keys

      commit_immediately = step_names.include? "confirm"

      parameters = {
        'client-id': client_id,
        intent: auto_capture ? "capture" : "authorize",
        commit: commit_immediately ? "false" : "true",
        components: options[:display_credit_messaging] ? "buttons,messages" : "buttons",
        currency: currency
      }

      "https://www.paypal.com/sdk/js?#{parameters.to_query}"
    end

PayPal SDK JS Error: Disallowed query param: shipping_preference

I had got some issue, with the version 0.3.2 of this gem, in the loading of the PayPal button on the checkout page because the javascript tag was not resolved and got 404. Further investigation got me to found that it was introduced shipping_preference but it was set in the wrong place.

In our solidus configuration we sell only digital products and we had disabled 'delivery' step from the checkout flow.

Thanks to the PayPal docs, shipping_preference should be in the application_context under order api rest as it is specified.

As say so, I had made a pull request with the correct behavior.

AVS & CVV response codes from PayPal

As far as I can tell, we don't get these response codes from PayPal, even when the user uses a credit card. We may need a separate call to get these, or maybe PayPal handles this part on their own?

Validate amount charged with PayPal

Because we're possibly changing the users address (and order total) after the payment has been created, we need to validate that PayPal has charged what we've told them to charge, and that the order total - given the new address - also matches that amount. If not, we should either:

• Invalidate/void the payment and redirect the user to the payment page again
  -or-
• Change the payment total and let Solidus handle the rest (if it's not enough it'll ask for more payment, if it's more it'll tell admin to refund)

Make the PayPal messaging component a bit more modular

PayPal recommends adding the messaging component near the product or order price. However, currently it's pretty difficult to actually move the messaging component. You have to override the PayPal buttons partial and remove the messaging div, to be able to include it anywhere else. We should make this process a bit easier somehow.

One complication to keep in mind is that PayPal really doesn't like their SDK to be included twice, even if for different things (one for messaging, one for buttons). But we'll need to include the SDK url in the messaging component, because if someone uses it in a page that doesn't have the PayPal SDK included, it won't work.

So we need one URL for the PayPal SDK, but it needs to know what components it's expected to load - buttons, messaging, or both - before being generated.

We also need to add a Messaging section to the README that explains about PayPals recommendations about messaging placement, and how to place it there.

There was a problem connecting with paypal.

Hey
after I changed the store default currency in spree.rb from USD to EUR or any other currency, I'm getting this message (There was a problem connecting with paypal.) when I'm clicking the PayPal buttons.
it working fine when it's on USD...
thanks :)

Store PayPal Debug ID

From the SOW:

 Paypal-Debug-Id header returned in the API Response should be stored on your system, so
that you can provide it to your PayPal Support teams for debugging any errors.

This can probably be stored on the response object for capture/refund/etc., so that when an admin views payment details they can see the debug info too.

Silent Failure In JS

I'm seeing this silent failure in JS in production.

The modal window just closes with no notification to the customer:

Anyone else seen this issue?

PayPal response address change

It's possible for users to change their shipping address in PayPal, which PayPal expects us to change on our end on return. The actual address change isn't a problem, but it does present one issue: Shipping costs.

If the address changes drastically, then the old shipping cost, and even method, may no longer apply to that order. I am not sure if changing the address also recalculates shipping costs (I don't think it does) but if it doesn't, the user would be able to check out with this new address and old shipping rate, creating confusion or shipping problems for admin.

For example, what happens if a user ships to Tennessee first, then changes their address to Hong Kong? They'd still have USPS First Class at $3.00 for their shipping cost.

I'm not sure how much we want to consider these edge cases, but if we do, then we'd want to direct the user back to the shipping method selection page if the address changes. Then, of course, we'll have to go through the payment step again, since the order cost potentially has changed. This could be confusing to the customer, as they've just told PayPal to approve a payment a few seconds ago, and now they have to do it again.

🤔

Add PayPal button to cart page

PayPal buttons need to be added to the cart page. This button will take the current cart, send it to PayPal, and let the customer complete the checkout process there. I still don't see any way to send shipping options to PayPal, so that part might be weird, but I'm sure there's a way.

Add `commit=false` to javascript SDK URL

https://developer.paypal.com/docs/checkout/integration-features/confirmation-page/

If the checkout steps contains confirmation, we should add commit=false to the SDK URL.

Extend lightbox during customer payment

The PayPal lightbox goes away as soon as the user returns from PayPal, however if the server responds slowly, this leaves some time where the user can navigate away from the page or click on something before being directed to complete their order... Which would cause problems. We can probably just re-enable the PayPal lightbox when we send off the request, then disable it when the request is done - by which point the user should be loading the confirmation page.

Backend users should be able to checkout & admin payments

I'm not sure what the best way to implement admin checkout is, but refunding, voiding, etc. should all be straightforward.

• Admin users can credit payments
• Admin users can void payments
• Admin users can create new PayPal payments using credit card
• Should admin users be able to create new PayPal payments? I'm sure there's a way to request payment, right? Or should we just do credit cards?
• Admin users should be able to see payment details

About the above: Admin users cannot process payments through this gateway, they HAVE to be customer initiated. However they can use the PayPal Virtual Terminal.

Admin users should be able to style the PayPal buttons on the payment_method show page

Doc: https://developer.paypal.com/docs/checkout/integration-features/customize-button/

Use combined_first_and_last_name_in_address? preference for solidus 3.0

On Solidus Support 3.0 PR I have switched the method to use based on solidus version, it would be nice to use this https://github.com/solidusio/solidus_support/blob/master/lib/solidus_support.rb#L24

PayPal uses different states than Solidus for some countries

Noticed about Italian addresses, but probably a valid issue in more countries.

PayPal sometimes uses different "states" than we use. For instance, in Italy. We use the Region for the state (e.g. "Abruzzo") where PayPal uses Province (e.g. Province of Pescara). This causes validation issues with the address. We probably don't want to bypass address validation... but we also probably don't want to write a state matcher class or something. Not sure what the solution is here. 🤔

Consider using one paypal order per each solidus order

Yes - multiple purchase units implies multiple payments, but Solidus handles multiple payments already... by creating new payments. And one payment should only have one capture. The way it's build now makes it impossible AFAIK to have multiple purchase_units.

However, now that we know more about the PayPal API, we could restructure the way we process the payments. In PayPal, you create an order, and that order can have multiple purchase units, which can have multiple captures. Purchase units can be used with partial orders, but since Solidus payments don't really care about partial orders (just the order total) I think we should stick with there being only one purchase_unit per order.

Currently we're structured as: Each payment has it's own PayPal order, which has one purchase unit and one capture

But we could structure it as: Each order has one Paypal order, which has one purchase unit, and each payment on the order has it's own capture.

However authorizing and capturing happens at the order level for PayPal, so while it conforms with our data a bit better, I'm not sure how much sense it makes. 🤔

Originally posted by @seand7565 in #21

Ensure the email is verified before activating the payment method

Related: #7

This can take the form of a button in the payment-method page that will trigger a new check on the verification, much like what happens when configuring a DNS and you're waiting for the nameservers to be updated.

The mockup is not binding in any way, but just a way to get started

Handle instrument declined errors

Right now the extension throws an exception on instrument declined from PayPal, ideally we should just display an error to the customer prompting them to try again with a different payment method.

Frontend users should be able to check out using PayPal

We've set up PayPal on the backend, now for the frontend!

• The buttons should display on the frontend
• They should either take you to PayPal to pay with your balance, or display a credit card form (all handled by PayPal thankfully!)
• We should have a server action that creates the order on PayPal when one of the buttons are clicked
• We should set up a server action for capturing (PayPal sends a request here after the user puts in there payment info - it shouldn't actually capture the payment, just add it to the order and proceed to the next step)
• We should handle failed payments gracefully #19
• On payment completion, the order should proceed normally, and have a capturable payment added to the order
• On order completion, payment method should either be charged, or be chargable by admin.

Unable To Cancel An Order

Version: solidus_paypal_commerce_platform (0.3.0)

Steps:

1. Create & Pay For An Order
2. Attempt To Cancel An Order In The Admin Panel

NotImplementedError (You need to implement try_void for SolidusPaypalCommercePlatform::PaymentMethod. In that return a ActiveMerchant::Billing::Response object if the void succeeds or false|nil if the void is not possible anymore. Solidus will refund the amount of the payment then.):

Setup proper testing harness

We should both provide the users and use ourselves reliable testing harness. This can take the form of a bogus gateway or pre-recorded VCR scenarios.

The support should include:

• onboarding
• usage from the solidus checkout
• usage from the solidus cart page
• usage from the product page

Allow users to onboard with PayPal

• Create a payment_method "wizard" 🧙 area that you can add setup info to (creating this separately in the hopes that it's ported to Solidus)
• Add a button to the wizard 🧙 that takes users to paypal from the payment_methods index page
• On user return, process the return data and create a payment_method from it.
• Make sure users have a flow where they can store credentials in env

It would be great to allow experienced users to bypass the onboarding flow if possible - if they already have their credentials, they could just add them to ENV and create a new payment method with paypal_commerce_platform, bypassing the need for onboarding. So I'm thinking:

Onboarding -> Credentials stored in preferences
Bypass onboarding -> Credentials stored in env

Not Applying Sales Tax

I've just attempting adding TaxJar calculations in conjunction with this Gem -- I'm using the from cart checkout option.

The behavior I'm seeing is that -- taxes are added to the order after the payment is captured in PayPal resulting in balance due on the order equal to the tax amount.

Any tricks for this?

Thanks

Allow checkout on product/cart page to complete the order

As of #43 , the user is always brought to the order confirmation page upon returning from checking out on PayPal. In some cases this is fine, but in cases where the confirmation checkout step doesn't exist, we'll want the PayPal checkout process to be able to complete the order instead.

Or maybe we should just add a bit to the README about it... Removing the confirmation step is a pretty big alteration to Solidus, so I don't think it's unreasonable if we didn't support it. Also, if they've customized the checkout heavily, it's likely whatever solution we put in place won't be sufficient. @elia what do you think?

Explore enabling the payment method by default

We've got the payment method disabled by default - because we want to ensure the users email is confirmed before proceeding. The current flow is:
Create payment method -> Set "PayPal Email Confirmed" to true -> Set "Available to Users" to true

Which is a bit unwieldy. I think enabling the payment method by default is fine, but then the "PayPal Email Confirmed" check is useless.

From Hai -

In the admin panel, the admin/merchant has to click “Available to users” — will this be enabled by default? I believe it should be to make the setup/onboarding process smoother for merchants.

Explore using Rails secrets to encode and decrypt PayPal client id and secret

https://github.com/rails/rails/blob/66cabeda2c46c582d19738e1318be8d59584cc5b/railties/lib/rails/secrets.rb#L38-L44

Prepare Solidus Paypal Commerce Platform for Solidus 3.0

Update this extension so that it works with Solidus 3.0 by making sure the specs pass.

We're using the wrong ID for paypal_order_id

From Hai -
In your admin/merchant panel I am seeing that you are displaying “PayPal Order ID” — This value is currently set to your id from your Create Order API. This id won’t be helpful the merchant. What you will want to display is the capture id returned from the capture call.

Implement and QA Paypal credit solutions

The extension is already outputting buttons for PayLater (one of Paypal's) latest credit solutions:

(thanks @seand7565 for the screenshot I stole from you during a call 😛)

So in a way this is already working. But we know we should make a few changes:

• add data-partner-attribution-id (https://developer.paypal.com/docs/platforms/checkout/reference/javascript-sdk/#script-parameters)
• enable messaging so credit information can be displayed (https://developer.paypal.com/docs/limited-release/sdk-credit-messaging/integrate)

After both are done everything should be QAed in some way.

Add this extension to demo store for integration team walkthrough

We need to walk through this integration with the PayPal integration team, adding it to the demo store seems like the perfect opportunity to do so - it's a store that's already running, allows anyone in as admin, and scopes every data change to the particular session the user is on.

"Something went wrong" after clicking the Accept and Integrate button on PayPal integration wizard page

The environment I used:
Rails 6.1.3 @ Local Development Environment
MacOS BigSur 11.2.3 Terminal
Ruby 3.0.1

What I have done:

1. Run the rails generate solidus_paypal_commerce_platform:install command
2. Configuring the Solidus PayPal API credentials on config/initializers/spree.rb with these lines

config.static_model_preferences.add(
    SolidusPaypalCommercePlatform::PaymentMethod,
    'paypal_commerce_platform_credentials', {
      test_mode: !Rails.env.production?,
      client_id: 'credential goes here',
      client_secret: 'credential goes here',
      display_on_product_page: true,
      display_on_cart: true,
    }
  )

How I reproduce the errors:

1. Login to Admin Panel
2. Go to Settings > Payment Page
3. Click the "Setup PayPal Commerce Platform" button
4. Fill in the email and password on PayPal Commerce Platform integration wizard popup from PayPal
5. Click the "Accept and Integrate" button
6. Popup closed and the admin panel says "Something went wrong"

Messages from Rails Console:

Started POST "/solidus_paypal_commerce_platform/wizard" for ::1 at 2021-06-09 22:33:18 +0700
Processing by SolidusPaypalCommercePlatform::WizardController#create as */*
  Parameters: {"authCode"=>"C21AAIERkUIiMjzR2HUuKm6BV53--PNPuN-RdzCTvDsXOEJT9_m7n5yN0gxiqNgIRaOFe5Tj1fkwAdfg9PjY2JEMcx6ZmXrYQ", "sharedId"=>"AWZG0SyysxSuqGnm4HZHKIYt2QLaNP2E4CwARJo5RSbnurdSVtQ6FavjIww7OusNGR24MqAKtc_x8jjO", "nonce"=>"xBRMZHxqyfpM2hNRD5tGhtDFRVtuI1Z5xhftE1KwiZB477UYkliUY5Kov4ioQd9qM151DbLmBIPOVrKMdqOVGnXrtQHpIhYVyNIJzS2Z8VYHHOdbnpeADI7khFxe60b5"}
  Spree::User Load (0.4ms)  SELECT "spree_users".* FROM "spree_users" WHERE "spree_users"."deleted_at" IS NULL AND "spree_users"."spree_api_key" = ? LIMIT ?  [["spree_api_key", "ca56066af735e67b192d66544ade6e9e09b46034c5be283e"], ["LIMIT", 1]]
   (0.1ms)  SELECT "spree_roles"."name" FROM "spree_roles" INNER JOIN "spree_roles_users" ON "spree_roles"."id" = "spree_roles_users"."role_id" WHERE "spree_roles_users"."user_id" = ?  [["user_id", 1]]
  Spree::Role Load (0.1ms)  SELECT "spree_roles".* FROM "spree_roles" INNER JOIN "spree_roles_users" ON "spree_roles"."id" = "spree_roles_users"."role_id" WHERE "spree_roles_users"."user_id" = ?  [["user_id", 1]]
Completed 500 Internal Server Error in 38ms (ActiveRecord: 0.6ms | Allocations: 7474)


  
NoMethodError (undefined method `escape' for URI:Module):
  
paypalhttp (1.0.0) lib/paypalhttp/serializers/form_encoded.rb:8:in `block in encode'
paypalhttp (1.0.0) lib/paypalhttp/serializers/form_encoded.rb:7:in `each'
paypalhttp (1.0.0) lib/paypalhttp/serializers/form_encoded.rb:7:in `encode'
paypalhttp (1.0.0) lib/paypalhttp/encoder.rb:23:in `serialize_request'
paypalhttp (1.0.0) lib/paypalhttp/http_client.rb:72:in `execute'
solidus_paypal_commerce_platform (0.3.2) lib/solidus_paypal_commerce_platform/client.rb:29:in `execute'
solidus_paypal_commerce_platform (0.3.2) lib/solidus_paypal_commerce_platform/client.rb:51:in `fetch_api_credentials'
solidus_paypal_commerce_platform (0.3.2) app/controllers/solidus_paypal_commerce_platform/wizard_controller.rb:40:in `api_credentials'
solidus_paypal_commerce_platform (0.3.2) app/controllers/solidus_paypal_commerce_platform/wizard_controller.rb:32:in `payment_method_params'
solidus_paypal_commerce_platform (0.3.2) app/controllers/solidus_paypal_commerce_platform/wizard_controller.rb:10:in `create'

Make this extension the default option for Solidus

Add PayPal button to product page

Like #26, we need to add a PayPal button to the product page. This will allow the user to check out completely on PayPals side. However, unlike #26, I think for this button we'll be sending only the product that this button was clicked on for, instead of the whole cart. Sort of like the instant checkout buttons with Amazon. I guess we'll use the quantity field to send how many of that product they want. This one might get a little hairy if the user already has an order in progress, because we'll need to create a new order on top of that one, but I'm sure we can figure that out.

Bad Request (400) when opening PayPal Payment Popup (eg clicking Pay with PayPal during checkout)

After successfully testing the installation locally, we are getting a new error on staging on Heroku.

Our set up:

• We're configuring the app using an initializer, aka:

Spree::Config.configure do |config|
  config.static_model_preferences.add(
    SolidusPaypalCommercePlatform::PaymentMethod,
    'paypal_commerce_platform_credentials', {
      test_mode: !Rails.env.production?,
      client_id: ENV['PAYPAL_CLIENT_ID'],
      client_secret: ENV['PAYPAL_CLIENT_SECRET'],
      display_on_product_page: true,
      display_on_cart: true
    }
  )
end

• The credentials we're using are from a business account created just for this app, loaded via env variables. More specifically, we are setting PAYPAL_CLIENT_ID and PAYPAL_CLIENT_SECRET, as well as defining PAYPAL_ENV=sandbox.
• We of course also set up the new payment method in the admin using paypal_commerce_platform_credentials as Preference Source.

Error Report:
At the payment step, the PayPal buttons show up as expected, but when clicking to use them a 'blank' pop up shows up (never loading the PayPal payment dialog).

Error message from the console:
GET https://staging-server-on-heroku.com/solidus_paypal_commerce_platform/paypal_orders/R684159333?payment_method_id=3&order_token=gtZcM_4Ksdb4aGFZjCah7Q 400 (Bad Request)

(We have tried using Live credentials and removing the env PAYPAL_ENV=sandbox and the error persists.)

@seand7565 suggested we also add the logs from the server, though as it turns out, they don't provide much info here.

2020-10-08T16:23:53.830581+00:00 heroku[router]: at=info method=GET path="/checkout/payment" host=staging-server-on-heroku.com request_id=fa66b7ee-5c5d-4374-9075-3ac875b9ce90 fwd="201.103.30.78" dyno=web.1 connect=1ms service=481ms status=200 bytes=45582 protocol=https
2020-10-08T16:24:02.607026+00:00 heroku[router]: at=info method=GET path="/solidus_paypal_commerce_platform/paypal_orders/R684159333?payment_method_id=3&order_token=gtZcM_4Ksdb4aGFZjCah7Q" host=staging-server-on-heroku.com request_id=19e29e53-9b25-4ca5-af13-12b88df29323 fwd="201.103.30.78" dyno=web.1 connect=1ms service=4ms status=400 bytes=268 protocol=https
2020-10-08T16:24:02.594794+00:00 app[web.1]: I, [2020-10-08T16:24:02.594677 #60]  INFO -- : [19e29e53-9b25-4ca5-af13-12b88df29323] Started GET "/solidus_paypal_commerce_platform/paypal_orders/R684159333?payment_method_id=3&order_token=gtZcM_4Ksdb4aGFZjCah7Q" for 201.103.30.78 at 2020-10-08 16:24:02 +0000

Any help is appreciated. From our research so far, it appears this could be coming from sending bad or incomplete order data to PayPal. We will keep digging into it.

Allow order simulator to be a configurable class

Since a lot of stores are heavily customized, the default order simulator may not use their logic for order total. To fix this, we should make the order simulator class configurable, so people can write their own.

PayPal email address needs to be included on the confirm step

From the SOW (about what you need to display after the user returns from PayPal):
PayPal as the selected payment method and Email Address from PayPal
PayPal is already selected - we just need to include the email address used. We can probably store this on the source?

Digital goods should be set as not requiring shipment

From the SOW:

If an order does not require any shipping information (Example: Digital Goods, Services), then
application_context>>shipping_preference in /v2/checkout/orders should be set to
NO_SHIPPING to suppress the shipping information on the PayPal Review page.

Perhaps we could implement a payment_method method that just returns true, expecting users to override the method if their store depends on digital goods?

def shipment_required?
  true
end

Should we enforce email address verification before allowing the payment method to be usable?

PayPal wants us to check the users email verification through an API endpoint before processing transactions. This seems like something that the user should verify on their own, but we do have an API endpoint for checking their email verification status, so we could prevent the payment method from being available to users before the email is verified?

`paypal_email_confirmed` is not an actual preference

# config/initializers/spree.rb
Spree::Config.configure do |config|
  config.static_model_preferences.add(
    SolidusPaypalCommercePlatform::PaymentMethod,
    'paypal_commerce_platform_credentials', {
      test_mode: !Rails.env.production?,
      client_id: ENV['PAYPAL_CLIENT_ID'],
      client_secret: ENV['PAYPAL_CLIENT_SECRET'],
      paypal_email_confirmed: true,
      display_on_product_page: true,
      display_on_cart: true,
    }
  )
end

paypal_email_confirmed is in this bit of code from the README, leading users to believe that it's an actual preference, but it's not - this code would cause an error on boot because of that.

I believe the intent behind this being a preference was to make 100% sure that users had the paypal email confirmed before using this payment method, but honestly, I think we can just drop that line from the README - I think it's a pretty obvious step, and we do mention it in big bold text right after that code in the README.

Thanks @MFRWDesign for pointing this out to me!

Add something to the README about backend payments

PayPals API does not allow for backend payments to be made - instead the user needs to use the PayPal Terminal. This is explained on the backend payments page when trying to select this payment method, but it would be nice to also add something about this to the README. Since most Solidus payment methods DO allow for payments on the backend, I think the difference is significant enough to warrant it.

PayPal payment Breaking flow?

I configured PayPal as an alternative payment method.

However, I can it is showing the payment buttons directly when I clicked on PayPal option instead of just let me select the option and continue the checkout flow (click on save and continue button -> review order and confirm -> (it should redirect to PayPal here and then go back to the complete page).

It seems the current flow is breaking this and making it confusing for users who see two options to continue (clicking on the PayPal buttons or the save and continue button, plus they can't confirm the order on site).

When I click on PayPal and hit con the "Save and Continue" button I also see an error "Payments source PayPal order can't be blank".

Is there any way around these two issues?

Change static sandbox URL and objects to dynamic

Right now we're using static Sandbox URLs from PayPal and objects from the SDK, but we should be using those dynamically depending on the environment - use sandbox unless Rails.env.production? == true

Add a URL generator for the PayPal JS SDK

Doc: https://developer.paypal.com/docs/checkout/reference/customize-sdk/?mark=javascript%20sdk#query-parameters

This can be either a helper or a class method (the latter makes sense because it's not dependent on anything), something along the lines of:

def paypal_javascript_sdk_url(client_id: …, …)

README lists two different types of PayPal credentials

The README has the following credentials being set:
PAYPAL_PARTNER_ID
PAYPAL_PARTNER_CLIENT_ID
PAYPAL_CLIENT_ID
PAYPAL_CLIENT_SECRET

Under normal circumstances, these are the ones that should be being set:
PAYPAL_CLIENT_ID
PAYPAL_CLIENT_SECRET
We probably don't want people overriding the partner_id information unless they're doing something super crazy, like building a marketplace. I think to avoid confusion (and people not using the default partner information), we should remove the references to the partner_id and partner_client_id from the README, or at the very least explain why they are there and that you probably should avoid setting them.

Invalid string length error

Looks like PayPal has max string length validations, and when a product's title is too long, a 422 is returned.

This happens when clicking one of the PayPal buttons on the cart or product page.

Here are the console errors:

and digging a bit deeper, PayPal returns:

{"table":{"status_code":422,"error":{"table":{"name":"INVALID_REQUEST","message":"Request is not well-formed, syntactically incorrect, or violates schema.","debug_id":"4365e6b61e3e","details":[{"table":{"field":"/purchase_units/@reference_id=='default'/items/0/name","value":"Guayaki Yerba Mate, Cranberry Pomegranate, Organic Sparkling Alternative to Soda, Tea, and Energy Drinks, 12 Ounce Cans (Pack of 12), 80mg Caffeine","location":"body","issue":"INVALID_STRING_LENGTH","description":"The value of a field is either too short or too long."},"modifiable":true}],"links":[{"table":{"href":"https://developer.paypal.com/docs/api/orders/v2/#error-INVALID_STRING_LENGTH","rel":"information_link","encType":"application/json"},"modifiable":true}]},"modifiable":true}}}

In this case, the product's title is:

Guayaki Yerba Mate, Cranberry Pomegranate, Organic Sparkling Alternative to Soda, Tea, and Energy Drinks, 12 Ounce Cans (Pack of 12), 80mg Caffeine

Simulated Address Info in Live Order

After successfully completing a live order in our staging environment, we observed an incorrect Shipping Address in the confirmation email that was sent from PayPal. The address was incorrectly using info from simulated_address for Name and Street Address, instead of using the real information that we had entered as part of our order.

https://monosnap.com/file/6f8t6lmOwjoPMKF2EekmstRUsX99FN

Explore subscribing to webhooks

From Hai -
Are you subscribed to any webhooks? Since this is a 1st party integration, you wouldn’t be able to subscribe to any onboarding webhooks. However, if every shopping cart comes with a webhook listener built in then you can still subscribe to payment/orders webhooks. For a full list of webhooks see this link. Once you have subscribed to the webhooks that works for your use case, please let me know and we can test it.
Link: https://developer.paypal.com/docs/api-basics/notifications/webhooks/event-names/#paypal-commerce-platform