src/server/routers/payment.ts (1)

6-35: Well-structured router implementation with room for improvement.

The implementation follows tRPC patterns well with protected routes, input validation, and error handling. A few suggestions to enhance this implementation:

1. The authentication check at lines 12-17 may be redundant since protectedProcedure should already ensure the user is authenticated.
2. Consider enhancing the error message at line 29 to include more details from the response for better debugging.
3. Add logging for successful/failed payment attempts to aid in monitoring and troubleshooting.

export const paymentRouter = router({
  pay: protectedProcedure
    .input(paymentFormSchema)
    .mutation(async ({ ctx, input }) => {
      const { user } = ctx;

-      if (!user) {
-        throw new TRPCError({
-          code: "UNAUTHORIZED",
-          message: "You must be logged in to pay",
-        });
-      }
+      // Authentication is already handled by protectedProcedure

      const response = await apiClient.post("v1/pay", {
        amount: input.amount.toString(),
        payee: input.payee,
        invoiceCurrency: input.invoiceCurrency,
        paymentCurrency: input.paymentCurrency,
      });

      if (response.status !== 201) {
        throw new TRPCError({
          code: "INTERNAL_SERVER_ERROR",
-          message: "Failed to pay",
+          message: `Failed to pay: ${response.status} ${response.statusText}`,
        });
      }

+      // Log successful payment
+      console.log(`Payment successful: ${input.amount} ${input.invoiceCurrency} to ${input.payee}`);

      return response.data;
    }),
});

src/lib/schemas/payment.ts (1)

1-17: Well-structured schema with appropriate validations.

The payment form schema properly validates all fields with meaningful error messages. Good use of the validator library for Ethereum address validation.

Consider enhancing the validation for paymentCurrency to ensure it's a valid currency code or from a predefined list, similar to how invoiceCurrency is validated:

-  paymentCurrency: z.string().min(1, "Payment currency is required"),
+  paymentCurrency: z.string().min(1, "Payment currency is required")
+    .refine(
+      (value) => ["ETH", "DAI", /* add other supported currencies */].includes(value),
+      "Invalid payment currency"
+    ),

src/components/background-wrapper.tsx (1)

26-49: Good implementation of color mapping function.

The getTailwindColor function provides a clean way to convert Tailwind color names to hex values, addressing the PR objective of replacing string interpolation with explicit values.

Consider extracting this color mapping to a separate utility file to avoid duplication if other components need the same functionality:

+ // src/lib/utils/tailwind-colors.ts
+ export const tailwindColors: Record<string, string> = {
+   // Orange colors
+   "orange-100": "#ffedd5",
+   "orange-200": "#fed7aa",
+   // Blue colors
+   "blue-100": "#dbeafe",
+   "blue-200": "#bfdbfe",
+   // Indigo colors
+   "indigo-100": "#e0e7ff",
+   "indigo-200": "#c7d2fe",
+   // Zinc colors
+   "zinc-100": "#f4f4f5",
+   "zinc-200": "#e4e4e7",
+ };
+ 
+ export function getTailwindColor(colorName: string): string {
+   return tailwindColors[colorName] || tailwindColors["zinc-100"]; // Default to zinc-100
+ }

// Then in background-wrapper.tsx
+ import { getTailwindColor } from "@/lib/utils/tailwind-colors";

- // Convert Tailwind color names to CSS variables or hex values
- const getTailwindColor = (colorName: string): string => {
-   const colors: Record<string, string> = {
-     // Orange colors
-     "orange-100": "#ffedd5",
-     "orange-200": "#fed7aa",
-
-     // Blue colors
-     "blue-100": "#dbeafe",
-     "blue-200": "#bfdbfe",
-
-     // Indigo colors
-     "indigo-100": "#e0e7ff",
-     "indigo-200": "#c7d2fe",
-
-     // Zinc colors
-     "zinc-100": "#f4f4f5",
-     "zinc-200": "#e4e4e7",
-
-     // Add any other colors you need here
-   };
-
-   return colors[colorName] || "#f4f4f5"; // Default to zinc-100 if color not found
- };

src/components/direct-payment.tsx (4)

91-97: Clarify the step reset logic when the wallet disconnects.
Switching back to step 1 clears the form context if the user has partially filled the payment fields. Consider preserving filled data in local state if you anticipate partial disconnection followed by reconnection.

---

167-177: Revisit automatic form reset after three seconds.
Automatically resetting the form can be surprising if users want to confirm the transaction details again or reference the final data. Consider letting the user reset manually or providing a visual countdown.

---

378-389: Expand on the security notice for higher user confidence.
While this section mentions blockchain transparency, consider also reminding users to double-check the payee address, confirm gas fees, and stay attentive to the wallet’s prompts to avoid potential phishing attacks.

---

397-400: Validate displayed address substring to improve UX.
Showing only a short substring of the connected address can be confusing if users deal with multiple wallets or addresses. You might supplement this display with a tooltip or button to copy the full address.

src/app/direct-payment/page.tsx (1)

27-39: Consider adding loading state during authentication

While the authentication logic is sound, there's no loading state displayed while checking the user session.

Consider adding a loading state to improve user experience:

export default async function DirectPaymentPage() {
  const { user } = await getCurrentSession();

  // Redirect to home if not logged in
  if (!user) {
    redirect("/");
  }

  return (
    <BackgroundWrapper
      topGradient={{ from: "blue-100", to: "indigo-200" }}
      bottomGradient={{ from: "zinc-100", to: "zinc-200" }}
    >
      <Header user={user} />
      <main className="flex-grow flex flex-col max-w-7xl mx-auto px-4 sm:px-6 lg:px-8 py-8 z-10">
+       {/* Page content */}
        <h1 className="mb-2 text-4xl font-bold tracking-tight">
          Direct Payment
        </h1>
        <p className="mb-8 text-lg text-muted-foreground">
          Send payments quickly without having to create a request first.
        </p>

        <DirectPayment />
      </main>
      <Footer />
    </BackgroundWrapper>
  );
}

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

Learnt from: aimensahnoun
PR: RequestNetwork/easy-invoice#21
File: src/components/background-wrapper.tsx:31-31
Timestamp: 2025-02-20T10:26:33.809Z
Learning: Dynamic Tailwind class interpolation for gradient classes (from-${color} and to-${color}) in the BackgroundWrapper component is intentionally implemented this way and doesn't require a mapping object solution.

src/components/direct-payment.tsx (4)

112-185: Consider breaking down the onSubmit function for better maintainability.

The current implementation is functional but quite lengthy. Consider extracting specific operations like approval handling, transaction execution, and success/error handling into separate helper functions.

-  const onSubmit = async (data: PaymentFormValues) => {
+  const handleApprovalTransaction = async (signer: ethers.providers.JsonRpcSigner, paymentData: any) => {
+    toast.info("Approval required", {
+      description: "Please approve the transaction in your wallet",
+    });
+
+    const approvalIndex = paymentData.metadata.approvalTransactionIndex;
+    const approvalTransaction = await signer.sendTransaction(
+      paymentData.transactions[approvalIndex],
+    );
+
+    await approvalTransaction.wait();
+    return true;
+  };
+
+  const handlePaymentTransaction = async (signer: ethers.providers.JsonRpcSigner, paymentData: any, isApprovalNeeded: boolean) => {
+    toast.info("Sending payment", {
+      description: "Please confirm the transaction in your wallet",
+    });
+
+    const paymentTransaction = await signer.sendTransaction(
+      paymentData.transactions[isApprovalNeeded ? 1 : 0],
+    );
+
+    await paymentTransaction.wait();
+  };
+
+  const resetFormAfterSuccess = (data: PaymentFormValues) => {
+    toast.success("Payment successful", {
+      description: `You've paid ${data.amount} ${formatCurrencyLabel(
+        data.invoiceCurrency,
+      )} to ${data.payee.substring(0, 6)}...${data.payee.substring(
+        data.payee.length - 4,
+      )}`,
+    });
+
+    setPaymentStatus("success");
+
+    // Reset form after successful payment
+    setTimeout(() => {
+      form.reset({
+        payee: "",
+        amount: 0,
+        invoiceCurrency: "USD",
+        paymentCurrency: "ETH-sepolia-sepolia",
+      });
+      setPaymentStatus("idle");
+    }, 3000);
+  };
+
+  const onSubmit = async (data: PaymentFormValues) => {

---

168-177: Extract the timeout duration as a constant.

The magic number 3000ms could be extracted to improve code readability and maintainability.

+const FORM_RESET_DELAY_MS = 3000;
+
 export function DirectPayment() {
   // Other code...

   // In the onSubmit function
-      }, 3000);
+      }, FORM_RESET_DELAY_MS);

---

397-400: Consider creating a reusable helper for address formatting.

The address truncation logic appears in multiple places (here and in the success toast). Creating a helper function would improve code maintainability.

+// Add to an appropriate utility file
+const formatAddress = (address: string | undefined): string => {
+  if (!address) return '';
+  return `${address.substring(0, 6)}...${address.substring(address.length - 4)}`;
+};

// Then use in the component
<span className="font-mono mr-2">
-  {address?.substring(0, 6)}...
-  {address?.substring(address?.length - 4)}
+  {formatAddress(address)}
</span>

// And in the success toast (line 158-163)
-  `You've paid ${data.amount} ${formatCurrencyLabel(
-    data.invoiceCurrency,
-  )} to ${data.payee.substring(0, 6)}...${data.payee.substring(
-    data.payee.length - 4,
-  )}`,
+  `You've paid ${data.amount} ${formatCurrencyLabel(data.invoiceCurrency)} to ${formatAddress(data.payee)}`,

---

177-185: Improve error handling with more specific error messages.

The current error handling doesn't distinguish between different types of errors. Consider adding more granular error handling to provide better feedback to users.

 } catch (error) {
   console.error("Payment error:", error);
+  
+  // More specific error messages based on error type
+  let errorMessage = "There was an error processing your payment. Please try again.";
+  
+  if (error instanceof Error) {
+    if (error.message.includes("user rejected")) {
+      errorMessage = "Transaction was rejected. Please try again when ready.";
+    } else if (error.message.includes("insufficient funds")) {
+      errorMessage = "Insufficient funds in your wallet to complete this transaction.";
+    } else if (error.message.includes("network")) {
+      errorMessage = "Network error. Please check your connection and try again.";
+    }
+  }
+  
   toast.error("Payment failed", {
-    description:
-      "There was an error processing your payment. Please try again.",
+    description: errorMessage,
   });
   setPaymentStatus("error");
 }

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

Learnt from: aimensahnoun
PR: RequestNetwork/easy-invoice#23
File: src/components/direct-payment.tsx:63-89
Timestamp: 2025-02-27T13:58:33.590Z
Learning: The AppKit wallet module requires initialization time before it's ready for use. A 2-second delay is intentionally used in the DirectPayment component to ensure the wallet is fully initialized before allowing interactions.