Great questions—let’s break this down clearly since you’re just getting started with integrating PayPal’s checkout flow!

1. Why use a relative path for CREATE_URL (and EXECUTE_URL)? #

Using a relative path instead of a full http/https URL is a practical best practice for a few key reasons:

• Environment flexibility: Your app will run on different domains during development (e.g., localhost:3000) and production (e.g., yourapp.com). A relative path automatically adapts to the current domain, so you don’t have to hardcode and update URLs for each environment.
• Simplified configuration: If your frontend and backend are hosted on the same origin (standard for most monolithic apps), relative paths work seamlessly without extra CORS (Cross-Origin Resource Sharing) setup.
• Maintainability: If you ever change your domain or subdomain, you won’t have to hunt down and update hardcoded URLs in your frontend code.

Note: If your frontend and backend are on separate domains (e.g., a standalone React app and Node.js API), you’ll need to use the full https URL for your backend endpoint—and ensure your backend is configured to allow CORS requests from your frontend domain.

2. What RequestBody should my REST controller accept? #

The structure depends on your business needs, but you’ll typically send order-specific details from the frontend to your backend to create an accurate PayPal order. A common example JSON body looks like this:

{
  "totalAmount": "29.99",
  "currency": "USD",
  "items": [
    {
      "name": "Premium Subscription",
      "quantity": "1",
      "unitAmount": "29.99"
    }
  ],
  "customerEmail": "user@example.com"
}

For testing, you might skip sending a RequestBody and use hardcoded test values in your backend—but for production, passing real order data is critical to avoid mismatches between your system and PayPal’s.

3. What operations should the CREATE_URL server endpoint perform? #

Your intuition is 100% correct! Here’s the step-by-step breakdown of what this endpoint needs to handle:

• Receive order data: Grab the RequestBody (if sent) with details like amount, items, and customer info.
• Create a database record: Insert a new order entry with a status like PENDING_PAYMENT, and store relevant details (including a placeholder for the upcoming PayPal order ID). This is essential for reconciling payments later and updating order statuses.
• Call PayPal’s Orders API: Make a POST request to PayPal’s sandbox endpoint (https://api-m.sandbox.paypal.com/v2/checkout/orders) or live endpoint with a properly formatted request body. A minimal example:

  {
    "intent": "CAPTURE",
    "purchase_units": [
      {
        "amount": {
          "currency_code": "USD",
          "value": "29.99"
        }
      }
    ]
  }
  

• Return the PayPal order ID: Once PayPal confirms the order creation, send back the id field from the response to your frontend. This is what the payment() function uses to proceed with the checkout flow.

For the EXECUTE_URL endpoint (triggered after the user approves payment), the workflow is similar but focused on capturing funds:

1. Receive the PayPal order ID from the frontend.
2. Call PayPal’s POST /v2/checkout/orders/{order_id}/capture endpoint to confirm and capture the payment.
3. Update your database order status to PAID or COMPLETED once the capture succeeds.
4. Handle post-payment logic (e.g., sending confirmation emails, activating subscriptions).

内容的提问来源于stack exchange，提问作者user1693207