Crea un ordine prima o dopo il pagamento su un sito e-commerce?

0

Ho un carrello della spesa con una pagina di pagamento. Nella pagina di pagamento è presente un pulsante di pagamento che li porta a un modulo di pagamento per le strisce.

Ho letto alcuni libri sulla costruzione di carrelli di eCommerce in cui l'ordine viene creato quando l'utente fa clic sul pulsante di pagamento e l'ID ordine viene passato al gateway di pagamento. In questo scenario, se l'utente abbandona il modulo di pagamento, viene lasciato un ordine non pagato collegato al proprio account.

Quindi la mia domanda è ciò che è preferibile. Crei l'ordine solo dopo l'addebito di un pagamento effettuato con successo o vuoi creare l'ordine prima che il pagamento venga effettuato?

Suppongo che l'unico vantaggio nella creazione di un ordine prima che il pagamento venga effettuato è che il sito diventa più flessibile nel senso che anche gli ordini offline possono essere fatti e cioè l'ordine fatturato.

* UPDATE *

Un esempio di come è possibile creare un ordine dopo aver addebitato il pagamento.

 public function checkout(Request $request)
{
    $token = $request->input('stripeToken');

    //Retriieve cart information
    $cart = Cart::where('user_id',Auth::user()->id)->first();
    $items = $cart->cartItems;
    $total=0;
    foreach($items as $item){
        $total+=$item->product->price;
    }
    if(
        Auth::user()->charge($total*100, [
        'source' => $token,
        'receipt_email' => Auth::user()->email,
    ])){

        $order = new Order();
        $order->total_paid= $total;
        $order->user_id=Auth::user()->id;
        $order->save();

        foreach($items as $item){
            $orderItem = new OrderItem();
            $orderItem->order_id=$order->id;
            $orderItem->product_id=$item->product->id;
            $orderItem->file_id=$item->product->file->id;
            $orderItem->save();

            CartItem::destroy($item->id);
    }
        return redirect('/order/'.$order->id);

    }else{
        return redirect('/cart');
    }

}
    
posta adam78 27.05.2016 - 22:21
fonte

5 risposte

2

Potrebbe esserci un modo per evitare questo problema girando "ordine" da un oggetto possibilmente transitorio in un'azione eseguita da un oggetto di cui si ha un controllo più diretto?

Assumiamo quattro tipi di oggetto (classi o prototipi, a seconda di cosa stai lavorando): Customer , Product , Cart e Receipt .

Per maggiore chiarezza, gli oggetti istanza sono lower_snake_case e le classi sono in StudlyCaps . Sto arrivando a questo da una prospettiva di Ruby e JavaScript, quindi traduci come necessario ...

  • A customer è un utente che fa acquisti sul tuo sito.
  • A product è un oggetto in vendita nel tuo negozio.
  • Un cart è un oggetto che rappresenta tutti product s nel carrello di un customer . Ogni customer ha solo un cart (per ora: vedi sotto). Quel singolo cart per customer può contenere molti product s, e ha una proprietà order_id che assume come valore predefinito null . I metodi di cart potrebbero includere manipolazioni del contenuto come empty , add([skus]) , remove([skus]) , increment(sku) e decrement(sku) . E poi c'è checkout , che popola order_id con un identificatore che non collide con altri ID ordine esistente (forse generato in base allo stato attuale cart , customer ID e ora) e invia quell'ID ordine e altre informazioni pertinenti al processore di pagamento. Alla conferma dal processore di pagamento di una transazione avvenuta con successo, il metodo pay converte i dati di cart in un'istanza Receipt e svuota il carrello degli acquisti.
  • Un receipt è come un cart conservato nel suo stato a pagamento finale. Un elenco di receipt s è ciò che un customer vede guardando la sua cronologia degli ordini. Ognuno ha alcune nuove proprietà come tracking_number e metodi come refund([skus]) .

Ecco come vedo questo in pratica:

  • Se il processore di pagamento risponde che la transazione ha avuto esito negativo, informa l'utente e ripristina order_id su null .
  • Se l'utente abbandona il processo di pagamento, la presenza di un% nonnull% diorder_id sul loro cart indicherà una transazione incompleta. Informare l'utente nell'interfaccia utente, insieme ai collegamenti per completare il checkout o visualizzare il carrello.
  • Se l'utente abbandona il pagamento, ritorna al sito e modifica il contenuto del proprio carrello quindi null ify order_id - questo è effettivamente un altro ordine.

Le cose belle di questo approccio:

  • Nessun ordine orfano in giro.
  • Ora disponi di una struttura che puoi utilizzare per aggiungere funzionalità aggiuntive. Ad esempio, potresti save a cart per trasformarlo in una "lista della spesa" o "lista dei desideri". Ciò svuoterebbe il carrello attivo corrente che l'utente considera come "il suo carrello della spesa", ma conserva i dati per la visualizzazione altrove nell'interfaccia utente. Quei carri salvati potrebbero quindi avere un pulsante "Acquista questo elenco" che salta direttamente alla cassa con quegli articoli, o un pulsante "Aggiungi al carrello" che unisce i contenuti della lista con cart attivo.
risposta data 28.05.2016 - 01:07
fonte
1

Risponderò alla tua domanda con due domande:

  1. È una cosa negativa cancellare un oggetto ordine?
  2. Un oggetto ordine non è valido se deve essere pagato (cioè non solo in attesa di essere pagato e prelevato) ma il pagamento non è stato superato?

Se la risposta ad entrambe le domande è "sì", allora non hai scelta. Un pagamento non riuscito ti lascerà in uno stato che richiede di eliminare l'oggetto ordine, che la tua architettura scoraggia.

Sembra una buona pratica astenersi dal creare oggetti che non sai di voler usare (quindi restrizione 0) e sembra quasi assiomatico che tu non voglia ordini fasulli nel tuo sistema che non saranno mai completato (quindi restrizione 1). Quindi la risposta migliore è che dovresti creare un ordine dopo che esegue il pagamento.

    
risposta data 27.05.2016 - 22:57
fonte
0

un modo per affrontare questo problema è considerare i vari stati di un ordine come entità separate. quindi, potresti avere (in un semplice esempio) qualcosa come OrderUnpaid , OrderPaid , OrderPaymentFailed , OrderCancelled , OrderApproved , OrderUnfulfilled , OrderFulfilled , OrderComplete . questo può essere utile perché consente una separazione intuitiva e chiara delle responsabilità in base alle esigenze immediate del processo dell'ordine.

    
risposta data 27.05.2016 - 23:46
fonte
0

Penso che un altro modo per farlo sarà enumerare l'ordine. Quindi l'ordine può essere incompleto, pagato o quale evento vorresti se la tua architettura lo supporta.

    
risposta data 05.11.2018 - 15:47
fonte
0

Normalmente nel mondo degli affari, un ordine potrebbe esistere in uno dei diversi stati:

  • Ora in costruzione.
  • Abbandonato.
  • Parcheggiato dall'utente che un giorno intende tornare ad esso e completarlo.
  • Inviato ma non ancora pagato.
  • Pagato per.
  • In attesa di ordine di acquisto; ordine di acquisto accettato; ordine di acquisto rifiutato.
  • Fulfilled.

Gli ordini vengono a volte accettati, soddisfatti e consegnati in base al credito di un cliente con la società o alla presenza di un ordine di acquisto che serve a promettere legalmente il pagamento in una data futura e così via. Comunemente, le transazioni finanziarie associate a un ordine sono gestite interamente separatamente dall'ordine stesso. La decisione di mettere un ordine nello stato di realizzazione attiva viene talvolta eseguita da un software; a volte solo da personale umano.

    
risposta data 05.11.2018 - 17:52
fonte

Leggi altre domande sui tag