行動支付繳稅推廣

本網頁僅為個人整理, 引用的資料可能異動而不符現況, 也不代表任何官方說法
行動支付是指使用行動裝置進行付款的服務；為便利民眾，政府也增加使用行動支付的方式繳稅，大約可分為遠端與近端兩種，特點如下：
遠端 近端
名稱 等 等(不含LINE Pay)
繳稅方式 網路繳稅 臨櫃繳稅
台南市財稅局全功能服務櫃檯:
嘉義區監理所稅務櫃檯:
支付工具
注意: 需搭配支援的手機與信用卡, 信用卡也要支援公務機關信用卡繳費平台才能用
例如: 渣打目前不支援
申請流程
繳稅方式 手機完成綁定信用卡之後, 持手機及稅單到財稅局及監理站據點, 由服務人員引導使用NFC感應扣款.
優惠 台灣Pay金融卡繳牌照稅抽MacBook Pro

可繳納稅目: 牌照稅(4月, 營業用10月再一期), 房屋稅(5月), 所得稅(5月), 地價稅(11月)

常見問題:
  • 台灣Pay: 需要以手機號碼註冊, 收到"簡訊認證碼"之後, 再設定"使用者自己設定的台灣Pay密碼", 要新增金融卡時, 要填寫銀行詢問的問題, 再收到"雲支付金融卡(虛擬金融卡)認證碼", 再設定"使用者這張雲支付(虛擬)金融卡密碼".

其他: 亦可申請約定轉帳納稅等方式.
如果您因為本網頁說明而申辦成功, 敬請回饋申請資料, 以便列入個人推廣業績.
於

撈資料與呈現的心得

這次的案例主要是, 人員有分總局跟分局,
分局要看分局所轄駐點全部的資料, 確定都有填報, 所以不管有沒有資料都要顯示.
總局要看全部分局所轄駐點, 但只要顯示有填報的資料.

在資料撈取的結構上, 切成 分局代號 , 駐點代號 , 項目 , 期別 ; 撈取的功能分成 明細 , 單項加總 ; 另外有一項功能是查詢最後修改的紀錄, 也用來判斷如果沒有修改記錄, 就不用再查明細跟加總.

資料結構上, 一個分局有多個駐點, 所以先依登入帳號屬於總局或分局, 撈取的駐點清單就加上條件(若是分局人員, 只撈取分局所轄駐點), 這樣雖然清單都是"駐點", 明細數量卻不同, 而主要程式結構就不變.

撈取駐點後, 依期別撈取所有已填寫的資料, 產生一個"實際填寫的項目(A)"陣列.
再來則是從項目清單與駐點清單, 產生一個"應該要有的項目(B)"陣列.

最後要轉成網頁畫面時, 再依登入人員決定要顯示的項目:
如果是分局, 就把整個"應該要有的項目"都呈現出來, 如果項目已經有填寫, 再顯示填寫的項目. (概念是B left join A)
而總局只需要已經填寫的項目, 所以是以實際填寫的項目, 把顯示的名稱撈出來. (概念是 A join B)

這樣整個程式大架構不變, 只有在物件導向的類別(class)加上參數, 撈取的資料就不同, 而顯示時, 也只要小幅度的判斷要顯示的部分, 其他部分都是讓迴圈自己跑.

而且這樣可以避免一種狀況, 就是有些寫法會先產生應有的項目, 再去資料庫指定要搜尋項目的值, 但這樣如果未填寫的部分, 因為資料不存在時, SQL 會將所有填寫明細表搜尋一次才確定為 NULL , 而花較久的時間.
於
行動支付, 雲支付, 電子票證, 電子票卡, TaiwanPay, 虛擬卡, 金融網路服務, 銀行網路APP, 銀行網路APP裡面的台灣Pay....

一堆很口語卻沒有架構的名詞, 只會讓行動支付更亂啊....

最傳統的是銀行帳戶(活儲存/活存/口褶), 然後定存(另一個帳戶但可以跟活儲存/活存互轉).
這帳戶的活儲存/活存, 可以透過"金融卡"提款, 之後又可以存款.

美國有兩大信用卡認證機制(VISA/Master), 日本有JCB, 原本是刷有凸起的卡號, 再簽帳(Credit); 在台灣則由透過銀行發行信用卡, 為了便利, 銀行也會將信用卡與自家的金融卡結合.

電子票證原本是為悠遊卡量身定做, 而市面上已經有iCash等業者自己發行的卡, 後來又有一卡通等, 這些卡總算有一個類似的規格, 就都歸類在電子票證, 都是在台灣非銀行業者發行.

信用卡業者也求發展, 所以又有兩種作法: 1. 感應式信用卡 2. 綁金融卡; 感應式信用卡的消費流程跟信用卡一樣, 差別只有刷卡方式; 綁金融卡則是透過信用卡認證, 但認證後直接由金融卡對應的活儲存/活存帳戶扣款(可能先圈存定額再實際扣消費金額.)

而許多公司都有預收會員費等機制, 加上網購平台等業者覺得傳統信用卡對於爭議款項處理麻煩, 而手機上網又開始盛行, 所以就有業者希望透過手機來處理金流, 把不同於以上的方式, 歸類出行動支付.

只是在台灣, 這些錢都需要被財金單位管理, 所以各業者的錢往往要存在指定帳戶內不能隨便動用, 行動支付業者多(目前有6~8間), 店家要處理的成本就高而降低意願.

而台灣Pay前身是T-wallet+, 由中華民國政府xx單位跟官股銀行一起來跟民間搶市場用的....把原本銀行的活儲存/活存, 透過HCE等機制, 產生手機APP內的特殊代碼(token), 想像成虛擬的另一張金融卡, 而可以透過QR code傳送指定的交易類型, 再使用手機內的虛擬金融卡, 由指定的銀行帳戶轉帳.

另外三大手機業者推出的GooglePay, ApplePay, SamsungPay, 則是原本手機內的信用卡付款機制, 除了買手機內的App外, 也建立虛擬的信用卡, 並在支援的店家, 透過NFC傳送手機內的虛擬信用卡(token)給信用卡業者認證, 但是在台灣因為要透過發卡銀行跟業者的刷卡機, 所以往往會出現"F家(合作的卡機業者)支援4間銀行的卡, S家(合作的卡機業者)只支援1間銀行"的限制....

這樣應該可以稍微解釋在台灣的行動支付為什麼這麼複雜了....因為銀行跟政府每個步驟都在檢核啊.... XD

於
訂閱： 文章 (Atom)