Skip to content
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

PayPal not capturing Authorized transactions when order is "Completed" #16802

Closed
6 of 7 tasks
FreshPhil opened this issue Sep 13, 2017 · 8 comments
Closed
6 of 7 tasks
Labels
type: bug The issue is a confirmed bug.
Milestone

Comments

@FreshPhil
Copy link

Prerequisites

  • I have searched for similar issues in both open and closed tickets and cannot find a duplicate
  • The issue still exists against the latest master branch of WooCommerce on Github (this is not the same version as on WordPress.org!)
  • I have attempted to find the simplest possible steps to reproduce the issue
  • I have included a failing test as a pull request (Optional)

Steps to reproduce the issue

  • Set PayPal's "Payment Action" to "Authorize" under WooCommerce > Settings > Checkout > PayPal
  • Make a new order and pay through PayPal
  • Mark the order as "Completed", either from the Orders overview tab, or from inside the individual order
  • Check order notes/payment logs, as well as PayPal to see that the authorization is not captured

This was confirmed with a live PayPal account (not sandbox)

Expected/actual behavior

When I follow those steps, I see...

  • The authorized order is not captured. No call is sent to PayPal to capture the order and the only way to do so is to log into your PayPal account and manually capture the authorization.
    I was expecting to see...
  • Once the authorized WooCommerce order is marked as Completed, the authorization should be captured in PayPal as per Paypal - 'Capture' payment when status changed #10563

Isolating the problem

  • This bug happens with only WooCommerce plugin active
  • This bug happens with a default WordPress theme active, or Storefront
  • I can reproduce this bug consistently using the steps above

WordPress Environment

``` ` ### WordPress Environment ###

Home URL: https://mystagingwebsite.com
Site URL: https://mystagingwebsite.com
WC Version: 3.2.0
Log Directory Writable: ✔
WP Version: 4.8.1
WP Multisite: –
WP Memory Limit: 256 MB
WP Debug Mode: –
WP Cron: ✔
Language: en_US

Server Environment

Server Info: nginx
PHP Version: 7.0.23
PHP Post Max Size: 100 MB
PHP Time Limit: 300
PHP Max Input Vars: 6144
cURL Version: 7.55.1
OpenSSL/1.0.1t

SUHOSIN Installed: –
Max Upload Size: 100 MB
Default Timezone is UTC: ✔
fsockopen/cURL: ✔
SoapClient: ✔
DOMDocument: ✔
GZip: ✔
Multibyte String: ✔
Remote Post: ✔
Remote Get: ✔

Database

WC Database Version: 3.2.0
WC Database Prefix: wp_
MaxMind GeoIP Database: ❌ The MaxMind GeoIP Database does not exist - Geolocation will not function. You can download and install it manually from http://dev.maxmind.com/geoip/legacy/geolite/ to the path: . Scroll down to "Downloads" and download the "Binary / gzip" file next to "GeoLite Country". Please remember to uncompress GeoIP.dat.gz and upload the GeoIP.dat file only.
Total Database Size: 2.58MB
Database Data Size: 1.70MB
Database Index Size: 0.88MB
wp_woocommerce_sessions: Data: 0.02MB + Index: 0.02MB
wp_woocommerce_api_keys: Data: 0.02MB + Index: 0.03MB
wp_woocommerce_attribute_taxonomies: Data: 0.02MB + Index: 0.02MB
wp_woocommerce_downloadable_product_permissions: Data: 0.02MB + Index: 0.05MB
wp_woocommerce_order_items: Data: 0.02MB + Index: 0.02MB
wp_woocommerce_order_itemmeta: Data: 0.02MB + Index: 0.03MB
wp_woocommerce_tax_rates: Data: 0.02MB + Index: 0.06MB
wp_woocommerce_tax_rate_locations: Data: 0.02MB + Index: 0.03MB
wp_woocommerce_shipping_zones: Data: 0.02MB + Index: 0.00MB
wp_woocommerce_shipping_zone_locations: Data: 0.02MB + Index: 0.03MB
wp_woocommerce_shipping_zone_methods: Data: 0.02MB + Index: 0.00MB
wp_woocommerce_payment_tokens: Data: 0.02MB + Index: 0.02MB
wp_woocommerce_payment_tokenmeta: Data: 0.02MB + Index: 0.03MB
wp_woocommerce_log: Data: 0.02MB + Index: 0.02MB
wp_commentmeta: Data: 0.02MB + Index: 0.03MB
wp_comments: Data: 0.02MB + Index: 0.09MB
wp_links: Data: 0.02MB + Index: 0.02MB
wp_options: Data: 1.02MB + Index: 0.02MB
wp_postmeta: Data: 0.14MB + Index: 0.11MB
wp_posts: Data: 0.08MB + Index: 0.06MB
wp_termmeta: Data: 0.02MB + Index: 0.03MB
wp_terms: Data: 0.02MB + Index: 0.03MB
wp_term_relationships: Data: 0.02MB + Index: 0.02MB
wp_term_taxonomy: Data: 0.02MB + Index: 0.03MB
wp_usermeta: Data: 0.02MB + Index: 0.03MB
wp_users: Data: 0.02MB + Index: 0.05MB

Post Type Counts

attachment: 36
customize_changeset: 1
page: 7
post: 1
product: 21
product_variation: 4
shop_order: 1

Security

Secure connection (HTTPS): ✔
Hide errors from visitors: ✔

Active Plugins (3)

Akismet Anti-Spam: by Automattic – 3.3.4
WooCommerce PayPal Express Checkout Gateway: by WooCommerce – 1.4.3 – Not tested with the active version of WooCommerce
WooCommerce: by Automattic – 3.2.0-beta.2

Settings

API Enabled: ✔
Force SSL: –
Currency: CAD ($)
Currency Position: left
Thousand Separator: ,
Decimal Separator: .
Number of Decimals: 2
Taxonomies: Product Types: external (external)
grouped (grouped)
simple (simple)
variable (variable)

Taxonomies: Product Visibility: exclude-from-catalog (exclude-from-catalog)
exclude-from-search (exclude-from-search)
featured (featured)
outofstock (outofstock)
rated-1 (rated-1)
rated-2 (rated-2)
rated-3 (rated-3)
rated-4 (rated-4)
rated-5 (rated-5)

WC Pages

Shop base: #4 - /shop/
Cart: #5 - /cart/
Checkout: #6 - /checkout/
My account: #7 - /my-account/
Terms and conditions: ❌ Page not set

Theme

Name: Storefront
Version: 2.2.5
Author URL: https://woocommerce.com/
Child Theme: ❌ – If you are modifying WooCommerce on a parent theme that you did not build personally we recommend using a child theme. See: How to create a child theme
WooCommerce Support: ✔

Templates

Overrides: –
`

</details>
@FreshPhil FreshPhil added the type: bug The issue is a confirmed bug. label Sep 13, 2017
@mikejolley
Copy link
Member

@FreshPhil have you confirmed this is a business account with the API creds added to the PayPal settings page? it's required.

@FreshPhil
Copy link
Author

@mikejolley the is a business account, however just the account & receiver emails were used (API creds were not added).

Are API creds required for this to send the capture request?

@mikejolley
Copy link
Member

Yes; the only way we can capture funds is via their API. Might be worth adding to the docs if it's not there.

#11544

To test this, you’ll need a paypal sandbox account (business) and API creds.

Thanks

@FreshPhil
Copy link
Author

Awesome, thank you - and yes I'll add that to the docs.

@FreshPhil
Copy link
Author

@mikejolley - Confirmed this is working when using the API credentials and editing the order to change the order status to processing or completed. However, if you use the "Complete" button from the Orders tab, it does not trigger the payment capture. Not sure if that is intentional or overlooked.

@mikejolley
Copy link
Member

That status change uses identical events. Anything in order notes?

@FreshPhil
Copy link
Author

FreshPhil commented Sep 14, 2017

@mikejolley - When using either "Complete", or "Processing" buttons, no order note updates and no entries in the PayPal logs:

Image Link: http://cld.wthms.co/8jktt

Video of attempting to capture the payment with the complete button:
http://cld.wthms.co/ABW52Y

When manually changing the status from within the order to completed or processing, the transaction is captured and the order notes are updated with the PayPal response:

Image Link: http://cld.wthms.co/apRF4i

@mikejolley
Copy link
Member

Will check.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug The issue is a confirmed bug.
Projects
None yet
Development

No branches or pull requests

3 participants