# 報價 2

## Requirement
這邊有另一個客戶想要做一個商品的購買系統，他主要是販售一個桌面軟體服務：
1. 使用者可以在頁面上看到商品介紹
2. 點選購買後，導向第三方金流
3. 購買完畢後：寄送Email給使用者 & 丟一筆會員訂單回公司內部的server (屆時後端會給對接格式）
4. 使用者一定要註冊會員後才能購買

邏輯圖如下：

## Questions

### 請問訂單查詢的細節內容包括哪些？
登入後，公司內部有訂單系統跟介面，導向過去即可

### 是否可以使用 Stripe 提供的現成第三方金流結帳頁面？
我查了一下stripe好像台灣好像沒有支援
詢問是否可以改成 Paypal

業者決定使用 TapPay
> TapPay 可能需要自行客製化表單設計

### 具體需要的開發頁面，目前我的理解如下，請問是否理解正確？
- Home
- Sign In
- Forgot Password
- Reset Password / Completed
- Registration Flow
- Form
- Email Validation
- Registration Completed
- Order Form
- Order Completed

### 首頁上的商品要從哪邊取得？
客戶的商品只有一個，所以僅需要寫靜態即可

### 程式碼要如何交付？
客戶有自己的伺服器，所以架在他們的server上面

### 會員註冊的相關資料，客戶會提供 API 還是 我們要自行開資料庫？
客戶會提供API，註冊完後寫入他們的資料庫中

### 那 Tappay 他們有決定用哪種支付方式了嗎
信用卡

### 對系統工程師的問題

XXX您好，
想跟你討論一下應用程式具體的交付方式，
但在進到具體方案前，先讓我們釐清一下前端預計會採用的模式，讓我們有個大致共識。

前端的應用程式，會採用 Server-Side Render (SSR) 技術，
白話來說，前端會有自己一個 Server，
粗略的 request 狀況大概如下：
Client Side App (用戶瀏覽器) -> Frontend Server -> API (貴方 Server)。

採用 SSR 技術將提供貴方，
1. 更好的 SEO
2. 更好的用戶體驗
3. 更簡單的部署
4. 保護貴方 API 的安全，因為只有 Frontend Server 會知道跟使用您的 API

所以，
關於部署層面，這邊有三個方案給您參考，並包含其優劣

1. 交付將包含 Dockerfile，直接使用 Docker 部署
- pros:
1. 不需要額外去深入了解應用程式細節
2. 減少額外的溝通成本
3. 因為 Docker 類似微型 VM，所以可能不需要額外思考應用程式運行環境
- cons:
1. 貴方的 server 必須能起 Docker
2. 貴方有一定程度了解如何使用 Docker (雖然我們並不會用到複雜的指令)
2. 交付程式運行文件，文件包含 command line 指令，由貴方按照文件啟用
- pros:
1. 少量了解應用程式細節
2. 少量程度的溝通成本
- cons:
1. 需要貴方的 Server 能夠支援應用程式運行的環境
2. 需要額外的時間成本討論細節
3. 由我方直接 Access 貴方 Server 進行部署
- pros:
1. 不需要額外去深入了解應用程式細節
2. 少量程度的溝通成本
- cons:
1. 資安方面的疑慮，我方不推薦讓我方可以進入貴方 Server

交付方面，我們會提供程式碼，並且會提供一定程度的 consult。
如果要求交付程式文件，需要貴方支付額外費用，並且我們會使用英文撰寫文件。

以上是我們這邊的想法，有任何更好的想法也歡迎提出我們在一同討論，感謝。