Laravel Laravel Package

Getting Started

• Install/update the package with Composer and confirm the SDK constraint resolves to p2flux/sdk-php 0.13 if you want return_url / checkout_url support:

  composer require p2flux/laravel
  composer update p2flux/sdk-php
  

• Publish/configure the package as documented, then set P2Flux credentials in .env.
• Look first at:
  • the package README payment examples,
  • config/p2flux.php if present,
  • the P2Flux facade,
  • the underlying p2flux/sdk-php createPayment() / createPaymentLink() signatures.
• First use case: create a hosted-checkout payment with a return_url, then redirect the buyer to the returned checkout_url.

use P2Flux;

$payment = P2Flux::createPayment([
    'amount' => 4999,
    'currency' => 'USD',
    'return_url' => route('checkout.return'),
    // other required payment fields per README/SDK
]);

return redirect()->away($payment['checkout_url']);

For payment links, pass return_url similarly and redirect to the returned checkout_url:

$link = P2Flux::createPaymentLink([
    'amount' => 4999,
    'currency' => 'USD',
    'return_url' => route('checkout.return'),
]);

return redirect()->away($link['checkout_url']);

Implementation Patterns

• Wrap P2Flux calls in an application service/action instead of calling the facade from controllers everywhere. This keeps payment creation, logging, and SDK upgrade handling in one place.
• Use a named Laravel route for return_url, e.g. route('checkout.return'), so the hosted checkout can return buyers to a stable page.
• Treat the return page as a UX handoff, not payment confirmation. After return, look up your local payment/order record and verify status server-side via webhook or SDK API call.
• Store the returned checkout_url and your local payment identifier before redirecting. This makes debugging and reconciliation easier.
• Use createPayment() for one-off checkout flows and createPaymentLink() when you need a reusable hosted payment link.
• Validate and normalize amounts/currency before passing them to the facade. Keep payment request data in a form request or DTO.
• Put credentials and environment-specific settings in .env / config, never in controllers or committed code.
• In tests, isolate the facade/SDK behind your own service or fake the HTTP/SDK layer if supported, so feature tests do not hit the real hosted checkout.

Gotchas and Tips

• return_url only controls where the buyer lands after hosted checkout. It is not proof that payment succeeded.
• checkout_url must be used as the redirect target after createPayment() / createPaymentLink(). Guard against it being missing if the SDK version or response shape is unexpected.
• The v0.5.1 release is additive: it allows p2flux/sdk-php 0.13 and passes return_url / checkout_url through the facade. Existing calls should continue working.
• If your lockfile pins an older SDK, return_url may not be available or may not behave as expected. Run composer show p2flux/sdk-php to confirm the installed version.
• Use an absolute, publicly reachable return URL in production. Avoid localhost URLs outside local development.
• Avoid putting sensitive data directly in return_url query parameters. Prefer a signed route or an opaque payment/order reference.
• Log the raw P2Flux response and the generated checkout_url during integration/debugging, but redact credentials and sensitive buyer data.
• Keep the facade behind your own service/action so future SDK upgrades or response changes do not leak across the codebase.
• If you support cancellation or delayed payments, design the return page to handle “pending”, “cancelled”, and “unknown” states rather than assuming every return is successful.